1. Introduction

This he use of mobile phones as a primary communication tool of today's vote cannot be denied even though it also can be used for many other purposes such as internet surfing, online transaction, texting and others. Because it is also used for various other activities, sometimes users will be faced with problems such as running out of battery. In some cases, voice communication via mobile phone held in a long time, can cause thermal-effect due to heat from the cell phone resulting to headaches, radiation and the like. [1, 2]. Sometimes, weather and the surrounding factors such as the obstacles of building or infrastructure can affect the signal strength of mobile data or WiFi. Then, the sound quality may affect the delivery of information especially if it requires immediate action.

Considering these situation, there are times when communication via PSTN [3] was chosen because of the cheaper bill, clearer sound quality and there was no heating problem when communicating [4]. However, PSTN phone cannot be simply moved as it already fixed at certain area. Hence there must be a flexibility between the use of mobile phone and PSTN. For this reason, we take the initiative to create a feasible study to provide a flexible relationship between the mobile phone and the PSTN. In this case users can communicate using mobile phone voice while on the go, that voice communication can be continued using the PSTN phone. In other words, voice communication can be transferred between the mobile phone to PSTN and vice versa.

Service transfer such as audio and video from a device to a different device has been much talked about in the previous study since it is an important medium currently. In [5-9] conducted a study on the efficiency of communication through the transition from one device to another device, from service provider to another service provider, and also from codec to another codec for the survival of the relationship.

In this paper, we introduce a method of transferring an ongoing voice communication on different protocol which is from IP to PSTN protocol. The method of device transfer between this two protocols has been implemented on an open source IP phone. Session Initiation Protocol (SIP) [10] was applied for signalling protocol. IP phone and correspondence party, i.e. PSTN phone were used and will be explained detail in the implementation section. This way, users are given the flexibility to move the live conversation from IP phone to PSTN phone and can also get back the communication by simply pressing the button that has been provided on the mobile phone interface. Generally, this feasibility study is to provide a more conducive communication services to users which is subject to the existing facilities in the surrounding area. Users may choose to transfer and retrieve the session without interrupt the session and unnoticed by their partner.

This paper is organized as follows- Section 2 gives a detail explanation on the project which include scenario of the prototype and component architecture. Section 3 describes on the project implementation that include prototype testbed while section 4 discusses on results. We conclude this paper in the Section 5.

2. Prototype Description

We describe detail about the prototype as follows:

2.1. Architecture

The implementation of an ongoing voice communication transfer from one device to another is done by exploiting an IMScore [11] defined by 3GPP as a framework. It has a capability to keep track of all communications session on any type of devices. SIP signaling protocol is applied in this application as it provides response request capability for users to communicate. IT also provides call-transfer capabilities to perform a transfer process. We applied this capabilities in our application to realize an ongoing voice transfer from IP phone to PSTN phone. As this project involved two different protocols, i.e. IP and PSTN, hence an intermediary is needed to do a translation between these two protocols. Therefore, Media Gateway, defined by 3GPP standard, is used to open up communication between the PSTN and IP protocol [12].

Figure 1 shows the position of Media Gateway that is between IP-based phone and PSTN phone. Using this mechanism, users can communicate between IP phone and PSTN phone, however, the handover process of the IP protocol and PSTN protocol (vice versa) that can be controlled by users could not be simply implemented. Thus, a transfer component should be built to manage a transfer of a caller live voice from IP to PSTN and take it back to the IP phone. This component was placed in the client device and can communicate with a media gateway for relaying instruction from the caller to the callee. According to the Figure 2, Transfer button will send instruction to the Transfer Component that can communicate with Media Gateway. This component is responsible to manage a transfer process by sending a message to the PSTN phone. While, Retrieve Component is responsible to retrieve back the session from PSTN phone to IP phone by sending a message to IP phone. During retrieving session, a message can be sent direct to the IP phone without a need to pass through the Media Gateway.

Figure 1. Media Gateway between IP and PSTN protocol

Figure 2. Transfer/Retrieve Component

2.2. Scenario

Mary has to attend a seminar outside of the office, but must drop by at her office for some matters. While on her way to her office, suddenly she receives a call from a customer, Khaty through her mobile phone. The conversation continues until Mary arrived to her desk in the office. Thinking that she might need to save her phone battery, as well as feeling more comfortable to communicate using PSTN phone, then Mary presses a button at her phone to do the transfer. The session is continued using Mary PSTN phone and her friend without interrupting or stopping the conversation and her friend is unaware of the transfer. After a moment, Mary need to leave the office, and still need to continue the conversation, and now Mary need to transfer back again the session from PSTN to her IP phone. By pressing the button at her IP phone, she can continue the conversation on her IP phone. Figure 3 depicts the explained scenario.

3. Prototype Implementation

We implemented the prototype through a few setting up and observation, explained as follows:

3.1. Testbed Setup

To test the ability of transferring a live call between IP and PSTN phone, a set of testbed was installed which includes following components:

Hardware setup

1. 3 clients – laptops that was installed with Linux. Two laptops was configured as an IP Phone, while another one was configured as PSTN phone.

2. A desktop, was configured as IMS/SIP server.

3. Media Gateway (from the Third Party).

Software setup

1. Linux had been installed in all of the clients laptop.

2. SIP server was installed in the desktop as a mediator for all IP-based phone. It also functioned as IMS-Server, communicated directly to the SIP server and Media Gateway.

3. K-phone was customized to fulfill the transfer and re-trieve requirement and was installed on the client device.

Figure 3. Transfer Retrieve Scenario

For the Client 1, it was setup as an IP phone, registered with the SIP URI as SIP:Mary@coitlab.net.my while another laptop as a correspondence node, registered as SIP:khaty@coitlab.net.my. The third laptop was configured as a PSTN client, registered with SIP URI, using a phone number, +0192197195.

3.2. Testbed Testing

Testing was done to see the ability of the transfer/retrieve module. Transfer/retrieve time were also recorded in order to ensure it was aligned with QoS [13, 14]. Tests were carried out as follows:-

Run the server of IMS and SIP server.

• Client 1 inviting Client 2 for an audio session after a connection is established.

• Client 1 pressed the Transfer button at the GUI application.

• Continue the audio session.

• Client 2 pressed the Retrieve Button at the GUI application.

• Continue the session.

• End the session by clicking the Abort button.

Figure 4. Testbed Layout

4. Result and Discussion

Based on the steps 1- 7 conducted, observation of the experiment were recorded as tabulated in the Table 1.

Table 1. Test Cases

The process of transfer to the PSTN phone and retrieve the session back from PSTN phone can be seen at the GUI of phone application, as shown by Figure 5. When transfer button is clicked, the message of Transfer in Progress will be displayed at the bottom of the phone lookup while when the Retrieve button is clicked, the Retrieve in progress message can be seen at the bottom of the GUI. This GUI is available at an IP phone application and accessible by users. As such, users can decide to make a session transfer and retrieve.

Figure 5. Transfer Retrieve Lookup

Transfer time is measured to fulfill the standard range of the voice QoS to be in the range of 0.15ms [13]. The transfer time starts when the transfer button is pressed until the audio is heard on the other device. In this test, the measurement of the time value is captured using Wireshark. Figure 6 shows one sample of Wireshark outlook that provides information regarding transfer and retrieve session through multiple SIP messages such as; INVITE, 200 OK, REFER, 202 ACCEPTED, 100 TRYING, 180 RINGING and BYE to show processes such as call, established, transfer, retrieve and terminate session.

Figure 6. Wireshark outlook for transfer and retrieve process

In order to obtain a constant data, transfer and retrieve session time was measured more than 10 times to avoid deviation issues. The time taken to transfer and retrieve was recorded as shown in Figure 7 below. The result shows that on average transfer time takes 1.004 seconds while retrieve time takes 0.903 seconds. Both of the time recorded is within the QoS range of 150ms, hence complying with the standard range of audio and video transfers.

Figure 7. Transfer Retrieve Timing

From the result, transfer time from IP to PSTN takes longer time compared to retrieve time from PSTN to IP. Reason being, during the transfer process from IP to PSTN the signal needs to pass through the Media Gateway to translate the signal from IP protocol to understandable protocol, while the translation is not needed during retrieving process.

As this test involves voice communication, quality of voice is also taken into consideration. The testing also covers tests for quality of voice done manually. Several test is done by asking users to manually hear the voice from the IP phone and PSTN phone during transfer and retrieve session. To measure the quality of audio we used Mean Opinion Score (MOS). The satisfaction level of users can be referred to the Table 2 [15].

Table 2. MOS Satisfaction Level

During the experiment, users are asked to listen to the quality of the audio before and after the traffic congestion. Results from the users are shown by graph shown in Figure 8.

Figure 8. Result of manual quality audio testing

5. Conclusions

We have elaborated the concept of voice transfer and retrieve between IP and PSTN, and also discussed the process flow between IP protocols to PSTN protocol by making use of IMS platform and Media Gateway for inter-protocol translation. The voice transfer on different-protocol of voice device was done through transfer/retrieve component built at application layer at client side, which is the IP phone. The testing covers observations done at the GUI of the application during transfer session as well as performance evaluation for transfer/retrieve time taken. Manual test on voice quality done shows that it complied with MOS level defined. Overall, this study met several objectives but several future works should be done to further improve the result. For example, to increase the number of users to see the ability of the project to handle multiple transfer / retrieve from several users at the same time. The study also was only covered the small scale to see the functionality of transfer and retrieve method between two different protocols. As such, further scenario should be taken into account to test it’s function successfully.