Ip Multimedia Subsystem

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, office 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 different 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, office 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 different 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 office 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 doesn't 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 specified groups and set the preferences for each group defining 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, defining 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. Effort 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 fix rules for four categories (friends, family, work, and others) prefixing as to where the calls should be routed in case a user belonging to any of the defined categories calls.

 GrandCentral One Number For Life Features:

According to [4], GrandCentral one number application has following features: i. Incoming phone calls rings on different phones according to which group you've placed a caller's 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 user's 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 predefined 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 official 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 predefined settings is web-based hence the user requires an internet enabled PC in order to make amendments to the contact list, re-define the ringing pattern for devices, etc. This is not a very efficient solution from user's 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 define 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 first 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 offer 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 defining the core elements and their functions in IMS system as well as finalized the Session Initiation Protocol (SIP) as the communication protocol. IMS is an open, unified architecture that defines 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 traffic over the IP layer and delivers the traffic to a server in accordance with the user profile and the application requirements instead of finding 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 figure: 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 defined 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 defined 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 user's service profile (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] defines 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 user's first 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 user's 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 find 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 Developer's Guide [12] explains the Serving-Call Session Control Function (S-CSCF) as an entity that communicates with the HSS to get the service profile for the user. The service profile contains one or many Initial Filter Criteria (iFC). The iFC defines 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 different 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 traffic needs to flow between networks using different 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 efficient and flexible 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 defined by Internet Engineering Task Force (ETF) in [RFC 3261] [13] for the creation and management of sessions over an IP network. RFC-3261 [13] defines 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 different services.

SIP Addressing:

The SIP architecture supports SIP URI (Universal Resource Identifier) based addressing to identify different users in the network. [13, 15] A SIP URI identifies 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 Martínez Perea in [14]. A SIP URI consists of an initial prefix “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 prefix ‘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 identifies 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 identifies 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] defines 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 defined 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 defined in [13] is shown bellow followed by the description of each field Request-Line = Method SP Request-URI SP SIP-Version Request Method: RFC-3261 [13] defines 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 Request–URI 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 specifications set out in RFC-3261.

SIP Responses:

RFC-3261 [13] defines 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 specified in RFC-3261 [13] is shown bellow followed by description of each field; Status-Line = SIP-Version Status-Code Reason-Phrase As explained earlier, SIP version is the protocol version of the SIP specification 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 defines 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 final 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 fulfilled at this server (e.g. 404 Not Found). 5xx: Server Error Response- meaning the server failed to fulfil an apparently valid request (e.g. 500 Server Internal Error). 6xx: Global Failure Response-the request cannot be fulfilled 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 significant 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 identified by a call identifier, 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 first user agent client. A SIP A/S can also generate one more provisional response before forwarding the final 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] defines two flavours 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] defines 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], defines 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 defines 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 defined 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 specification RFC-2327 [15] defines a session as, "A set of multimedia senders and receivers and the data streams flowing 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 flow 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 first flows to an intermediate server known as SIP Application Server shown as SIP-AS in the figure:3a, which sends back a provisional response (non-final 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 final 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 figure: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 Profile (MIDP2.0) [Appendix-2] and Connected Limited Device Configuration (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 different 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 efficient 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 efficient 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 specifications.

Features:

i. Open source, distributed under General Public Licence (GPL). ii. Easy to configure 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 five HTTP1.1 compliant servlets each for different data storage and retrieval operations. Following are the main functions performed by Tomcat Server;

1. Hosts five different HTTP servlets, each different for different database operation.
2. Can create HTTP sessions with mobile platform.
3. Establishes connection with MySQL database system using MySQL JDBC driver instance.
4. Queries the MySQL database system according to the requests of mobile platform.
5. 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 defined within the MySQL server. The mainDataBase as its name suggests is the central database where entire user related data i.e. User's 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 subscriber's devices. iii. Stores the call routing rules for different 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 figure 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 defined 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 five columns (Group, Home, Cell, Office and PDA). First column, Group, stores the name of the group for which the rules are being specified. 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 first 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, Office and PDA) specified 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 figure: 4d; 1. When a subscriber wants to make the amendments in predefined 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 confirming 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 Glassfish server. Vince Kraemer, a key developer involved in the SailFin projectin [19] defines 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 configure. 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 different parameters and forwards it to the callee. ii. It can forward the callee's 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 subscriber's preference for incoming calls. viii. Can query the mainDataBase and retrieve the data such as call routing rules, SIP URI for the subscriber's devices, etc. ix. Can create and send the BYE request to either of callee or the caller depending on who initiates the session termination first.

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 Developer's 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 studio's 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 profiles, service profiles, and Public Service Identity (PSI) profiles. [12]

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

As explained in Ericsson Developer's Guide [12], The PCSCF is the first 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 Developer's 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 find these clients and messages can be routed to them. The S-CSCF also contains the service profile of the users and PSIs (Public Service Ids). The service profile 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 Developer's Guide [12] explains the DNS from service point of view, the DNS resolves the general call flow 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 Profile as well as User Profile 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 first comes at the Proxy Call Session Control Function (P-CSCF) which is the first point of contact in the virtual IMS setup.
2. The P-CSCF first 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 notifies 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 Profile of the subscriber.

5. HSS checks the initial Filter criteria (iFC) and Service Point Trigger (SPT) in the service profile 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 first 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 query's 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 flow 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 flow diagram illustrates the SIP messages as they flow 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 enquiry's 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 specified 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 first.

Development Of One Number Service

This chapter includes a brief description of the development details. It first explains the Integrated Development Environment (IDE) used in the development of the One Number Service. In addition, it also explains the process of the configuration 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 defined 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 offered by next-generation IMS networks.

Ericsson Service Development Studio (SDS) Features:

Ericsson SDS 4.1 Developer's Guide [12] enlists following main features of Ericsson SDS;

1. Ericsson's 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 find out whether or not it is feasible to create and offer 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.

Configuration of Ericsson SDS 4.1 For One Number Service Development:

Before moving on to the details of programming, let us first see how the Ericsson SDS is configured 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 preconfigured, 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 configured 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.

Configuring 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 configured 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 Tomcat's 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 finish, the icon of Tomcat server can be seen in the Server tab of the SDS.

Configuring MySQL Server 5.0 In Ericsson SDS:

Since MySQL is not compatible with Ericsson SDS, MySQL Server needs to be configured 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 profile in the studio environment. The connection profile 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 Profile type from the list of available types, mention a unique name for Connection Profile and click Next.
4. Select the driver name from the drop down list or browse to the location of the .jar file 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 fine.
7. Click finish. A complete hierarchy of the database will be shown in the Data Source Explorer.

Configuring 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 file 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 file 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.

Configuring 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 configured 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 (‘Sailfin v1 at local host' in this case) and then click Next.
4. Select the Sailfin-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 finish, the icon of SailFin server can be seen in the server tab of the SDS.

Configuring 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 configure 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 zipfile and copy the mysql-connector-java-5.1.8-bin.jar to the SailFin installation directory which for this development machine is C:EricssonSDS4.1FD1Simulatorssailfinlib. 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 configuration 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 figure: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 Profile (MIDP2.0) [Appendix-3] and Connected Limited Device Configuration (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 efficient 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 five 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 first page that a user comes across when he/she runs the OneNumberService MIDlet suit. When OneNumberService MIDlet suit is run for the first 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 define the visual interface of the MIDlet. Like any other basic MIDlet, there are three methods defined 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 defined in them. The startApp() method is further explained bellow; startApp(): The startApp method first 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, textfields, 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 defined 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 effect 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) defined 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 five 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 defined in this MIDlet which is used to establish HTTP sessions with the Tomcat server. The methods defined in Contacts MIDlet are further explained in the following paragraphs. StartApp( ): The startApp( ) first 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 textfield, SIP URI textfield, 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 textfields 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 specified in the open method for the Contacts MIDlet is https://localhost:8080/ServerProgrammz/ServletServer01. This URL specifies 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 confirm 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( ) first 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), Office 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 textfield, Cell Phone textfield, Office Phone textfield and Voicemail textfield 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, Office Phone and Voicemail Textfields 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 specified in the open method is https://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 confirm 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 defined in this MIDlet which is used to establish HTTP sessions with the Tomcat server. The methods defined 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("https://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 profile. This tells the server abut the originator of the request. httpConn.setRequestProperty("User-Agent", "Profile/MIDP-2.0 Confirguration/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 Buffer to hold the values received from the server. StringBuffer sb = new StringBuffer(); 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 buffer 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 textfield 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 Textfield 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 first 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 specified in the open ( ) method is https://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 confirm 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 defined in this MIDlet which is used to establish HTTP sessions with the Tomcat server. The methods defined 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 different 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, Office 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, Office 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 confirms 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 defined 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 figure:5c, there are five Servlets defined in the HTTP suit each performing different operation on the MySQL database mainDataBase. Function of each is detailed bellow.

ServletServer01:

OneNumberService MIDlet suit's 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 first ends up in ServletServer01.

DoPost method():

The only method defined 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 first 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( ) finally 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 first ends up in ServletServer02. The function of ServletServer02 is similar the only difference 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, Office 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 first ends up in ServletServer03. Like previous two servlets, the function of ServletServer03 is pretty much the same, only difference 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 first ends up in ServletServer04. Like other three servlets, the function of ServletServer04 is pretty much the same the only difference 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, ringingOrderOfficePhone, 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 difference 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 defined 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(ServletConfig):

The init(ServletConfig) method initializes the OneNumberSIPServlet class. The ServletConfig is used to get an instance of ServletContext. According to JSR-289 specifications [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 first 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 first creates TRYING response using the createResponse( ) method of SipServletRequest class. The createResponse( ) takes an integer attribute which specifies 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 finds 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 query's 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 Callee's 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 notifies 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 Profile 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: Office 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: Office 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 first directed to the device with ring pattern ‘1', and then to the device with ring pattern ‘2'only if the user fails to pick the call at first device. The figure: 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-final response that notifies the caller of the progress of the call. TRYING or RINGING response is an example of provisional response. In OneNumberServiceB2BUA Servlet, doProvisionalResponse( ) method first 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 figure:5g shows the SIP message flow 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 specifications (RFC-3261 [13]), a BYE request needs to be sent to terminate the session. The doBye( ) method does just that, it first 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 off 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 affirms 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 find 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 defined 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 find 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, Textfields, 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 file 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 defined in the OneNumberService MIDlet suit. An example code statement to define 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 defined 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 defined 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 defined 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 defined in the LWUI toolkit and does not make any amendments to them. Transitions: The Transition object defines 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 defines 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 verification procedures taken to test the working principle of one number service.

Test Approach

One Number Service is a telecom Value Added Service that consolidates user's 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 specifically 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 flow 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 profiles 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 flow 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 figure: 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 subscriber's 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 Profiles, User Profiles, and Public Service Identity (PSI) Profiles. 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 Profile, and PSI Profile 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 subscriber's service related parameters, the HSS first checks the initial filter 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 Profile and User Profile and PSI Profile.
2. Select the iFC tab. The iFC contains two tabs; Definition tab where iFCs are defined and SPT tab where services are defined which iFC triggers.
3. In the Definition tab, click Add and enter the information asked on the right side to define 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 profile which means there is no set rule to trigger this servlet.

Setting Service Profile:

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

1. In the HSS perspective view, click on the Service profile tab.
2. Click on Add button and define a new service profile.
3. Enter the name of the new service profile. The name entered for the service profile is OneNumberService Profile.
4. Check the name of the iFCs that needs to be included in this service profile and Click on Save button to save the information. OneNumberiFC is checked in this case.

Setting User Profile:

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

1. In the HSS perspective view, click on the User profile 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 profile to which this device is associated, for OneNumberSIP servlet the device is associated with default service profile ‘profile'.

Setting PSI Profile:

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 profile 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 defined as follows,

1. In the HSS perspective view, click on the PSI Profile tab.
2. Click on Add button to enter a new PSI profile 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 Profile (the services this user authorised to use) associated with this PSI profile and click on Save to save the changes.
5. The figure: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 flaws of one number service.

Pass/Fail criteria:

In order to confirm 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;

1. Successful SIP session/call establishment, compliant with Three-way handshake scheme as specified in SIP specification (RFC-3261).
2. Successful SIP session/call termination, as specified by SIP specification (RFC-3261).
3. Successful database update.
4. Successful database edit.

Test Cases:

Testing The Database Connectivity:

Adding Numbers In The Database

When a subscriber starts the one number service for the first time, he/she has to add the SIP URI of all of his/her devices to the mainDataBase database. The first 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), first test will also confirm 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 first 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, office 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 figure.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 (figure:6i(ii)). 4. Enter new SIP URI for this device and click save, a dialog box will appear confirming the SIP URI update (figure: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 predefined 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 figure:6j(i). 3. Enter the information asked and click on Add (figure:6j(ii)), a dialog box will appear showing the database update success as show in (figure: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 five 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 office 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 figure: 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 specified domain (ericsson.com). From Test Agent 1 (Alice's 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 figure: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 figure: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 (Office Phone) get the INVITE request sent by the Test Agent 1 simultaneously. This is shown in figure: 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 figure: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 figure:6p(vi). The OneNumberSIPServlet sends the ACK request to the Test Agent 2 (Kumar), as shown in figure: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 Kumar's 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 first device. The Test Case-2 is similar to test case-1, only difference 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]/* */, Office- sip:[email protected]/* */ respectively in SIP Registrar. Three registered Test agents are shown in figure 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 first, this is shown in figure: 6q(i). 11. Callee (Kumar) does not pick the call at Test Agent 3, the call is redirected to Test Agent 4 (Office 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 ‘Office'. 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 ‘Office'.

Test Case-2 Result:

A call is successfully established between the caller (Alice) and the callee (Kumar) on callee Kumar's Office phone.

Alternate Forking:

In alternate forking, user's first two devices are ringed in parallel and if the user is not able to answer on any of the first 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]/* */, Office- sip:[email protected]/* */ respectively in SIP Registrar. Three test agents are shown in figure: 6m, 6n, 6o respectively. Three test agents are shown in figure: 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 figure: 6r(i). 10. Callee (Kumar) does not pick the call at first two phones i.e. at Test Agent 2 and Test Agent 3, the call is redirected to Test Agent 4 (Office) 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 ‘Office'. 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 Kumar's Office 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 operator's 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 figure shows the test environment-2. Test environment-2 is almost similar to test environment-1, the difference 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 SDS's IMS based virtual Service Execution Environment (SEE). For one number service testing, the Media Gateway (MGW) in IMS Next-Gen Lab has been configured 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) Configuration:

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 first converted to a Signalling System 7 media format in order for the calls to be routed in a circuit switched network. The figure: 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.

Configuration 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 configured with the name Alhad and SIP URI: sip:[email protected]/* */:5060. Figure: 6s(iii) shows the configuration 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 configured on three different 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.

Modification 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 modified 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 Khalid's database.
2. The call is first 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 Khalid's 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 confirmed 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 confirms the call establishment. This is shown in figure: 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 user's 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 defining 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 predefined groups.
• User can set the call routing rules for different 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. Ericsson's 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 simplifies user's 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 subscriber's current location; there is no mechanism that can find out the current location and availability of subscriber. For future work, a location based service is suggested that can find out the subscriber's most recent location and availability and forwards the calls accordingly. For instance, if the presence of subscriber is on office 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 fit 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 specific 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 modified to include the SIP servlet that can process user's 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], defines three Header fields i.e. Request Disposition, Accept Request and Reject Request which can be used to command the SIP server to route the call based on user's preferences.

References:

[1] Session Initiation Protocol SIP Servlet 1.1 Final Release Java Specification Request (JSR) -289, Java community Process. https://jcp.org/en/jsr/detail?id=289 [Accessed 12th June 2009] [2] GrandCentral “One Number for Life” Service. [Internet] https://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 https://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 https://www.techcrunch.com/2006/09/25/grandcentral-could-make-phones-lovable-again/ [Accessed September 2nd 2009] [5] Jajah Global phone to phone service, https://www.jajah.com/ [Accessed September 2nd 2009] [6] Google Voice official website. [Internet] https://www.voice.google.com [Accessed September 2nd 2009] [7] LinxCom's official web page for LinxConnect ‘One Number Service'. [Internet] https://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 https://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 https://www.ericsson.com/developer/sub/open/technologies/technologyinbrief/index/IMS [Accessed September 18th 2009] [10] 3rd Generation Partnership Project 3GPP, IMS release 6. [Internet] https://www.3gpp.org/article/ims [Accessed September 2nd 2009] [11] UMTS Forum Official web-site www.umts-forum.org [Accessed September 4th 2009] [12] Ericsson SDS Developer's Guide- dispatched with Ericsson Service Development Studio FD 4.1. [Internet] Available from https://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] https://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 https://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. https://www.ietf.org/rfc/rfc2327.txt [16] Rogelio Martínez 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) official web site (https://www.isc.org/index.pl?/sw/bind/index.php). [Accessed September 10th-2009] [18] SailFin Server Documentation https://sailfin.dev.java.net/documentation/ [Accessed August 20th-2009] [19] Geertjan Wielenga, “SailFin: When Java EE Met SIP Submitted” March 3rd 2008. https://netbeans.dzone.com/news/sailfin-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] https://blogs.sun.com/prsad/entry/sailfin_and_glassfish [Accessed August 22nd -2009] [21] Albin Joseph, “Creating and Configuring a mysql-datasource in glassfish-application server”, 6th August 2008 [Internet] https://www.albeesonline.com/blog/2008/08/06/creating-and-configuring-a-mysql-datasource-in-glassfish-application-server [Accessed August 8th 2009] [23] MySQL Server 5.0 official web site. [Internet] https://dev.mysql.com/downloads/mysql/5.0.html [Accessed July 22nd 2009] [24] MySQL Connector/J, the official Java Database Connectivity (JDBC) driver for MySQL. [Internet] Download Site: https://dev.mysql.com/downloads/connector/j/3.1.html [Accessed August 8th 2009] [25] Light Weight User Interface Toolkit (LWUI) Toolkit: Java.net's official 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] https://www.ietf.org/rfc/rfc3261.txt [Accessed September 22nd 2009] [27] Tomcat Installation Procedure, Tomcat 6.0 Documentation, Tomcat 6.0 Official Site. [Internet] https://tomcat.apache.org/tomcat-6.0-doc/setup.html [Accessed July 12th 2009] [28] Sun's Official webpage for Java 2 Micro Edition. [Internet] https://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 Identifier MIDlet: Mobile Information Device toolkit MIDP: Mobile Information Device Profile J2ME: Java Platform, Micro Edition J2SE: Java Platform, Standard Edition JSR: Java Specification Request RFC: request For Comments CLDC: Connected Limited Device Configuration 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 Profile (MIDP) lets a developer write applications and services for network-connectable mobile devices. When combined with the Connected Limited Device Configuration (CLDC), MIDP is the Java runtime environment for today's most popular compact mobile information devices, such as cell phones and mainstream PDAs. [https://java.sun.com/products/midp/] CLDC: The Connected Limited Device Configuration (CLDC) defines 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 profile such as the Mobile Information Device Profile (MIDP), it provides a solid Java platform for developing applications to run on devices with limited memory, processing power, and graphical capabilities. [https://java.sun.com/products/cldc/] Midlet: A Mobile Information Device toolkit is a Java application framework for the Mobile Information Device Profile (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. [https://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, flexible environment for applications running on mobile and other embedded devices—mobile phones, personal digital assistants (PDAs), TV set-top boxes, and printers. Java ME includes flexible user interfaces, robust security, built-in network protocols, and support for networked and offline applications that can be downloaded dynamically. Applications based on Java ME are portable across many devices, yet leverage each device's native capabilities. [https://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) specification and the Mobile Service Architecture (MSA, JSR 248) specification. It consists of build tools, utilities, and a device emulator. [https://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 defines 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 final response.

Cite this page