Mobility Project - VoIP over 3G/WiFi networks Gaël ALLOYER, Marc CABOCEL, Romain CASTAGNET, Pascal CLEMENT, Pierre LEROY, Guillaume LESNE, Nicolas PEPIN [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected] Abstract. With the increasing of mobility of devices and Internet expansion, users are constantly connected. In this con- text, the aim is to study if it is possible to create a Voice over IP application for Android and iPhone OS in order to be able to switch between networks to maintain Internet connection. Swapping between networks has to be without discon- nection. A VoIP application dealing with this mobility problem has already been implemented for Linux. This report pre- sents our approach to port a similar application for smartphones. Our results show that smartphones cannot always be considered as small computers with an easy development platform. Access and management restrictions can cause nu- merous problems for developers for this software migration on iPhone OS and Android. 1 Mobility Management The aim of this project is to develop a VoIP (Voice over IP) application with mobility on two mobile OS, iOS and Android. This application allows the user to switch between two networks without any disconnection during a communication. This project is based on a mobility patch created for an open-source project named PJSIP [1], which provides source codes writ- ten in C language to build VoIP applications. This patch modifies PJSIP libraries (PJLIB) [2] and PJSUA [3], a UNIX VoIP application for testing purposes that uses PJSIP. The patched version of PJSUA already allows mobility management. 1.1 Context SIP/RTP. SIP is a signaling protocol used in VoIP. RTP is used for media transport. IMS. The IMS is an architectural framework delivering Internet Protocol multimedia services. The IMS server provides a database of subscribed users that are allowed to interact with other subscribers using SIP/RTP protocols. In order to provide Voice over IP, an IMS (IP Multimedia Subsystem) server providing VoIP services was installed. Routers. Users have access to the IMS through two routers, one configured as a public router where accessible through 3G networks, and the other through WiFi. These devices constitute a simulation bench for access switching on mobile devices. Available Patch. The patched version of PJLIB provides a good starting point to implement mobility on iOS and Android. iPJSUA is an iPhone application that uses PJLIB, as well as CSipSimple [5], a similar application for Android. 1.2 Research Before implementing the managing of mobility on a smartphone using PJSIP, the context has to be fully understood. During a communication between two devices, packets pass through an IMS proxy (P-CSCF) and the IMS core before passing through another IMS proxy. This leads to the device called. Calling Process (Figure 1). Firstly, the calling device uses SIP protocol in order to register itself in the IMS (by sending a REGISTER SIP packet). Then the user can make a call (by sending an INVITE SIP packet). If the IMS accepts the registra- tion, and the correspondent answers the call, communication begins. RTP packets carrying the voice are exchanged be- tween the two devices. 1 of 8 Figure 1. Calling process Mobility Management. With mobility management, this process is slightly modified. The communication has to switch between two network interfaces (e.g. WiFi to 3G) without any disconnection. The device has to be connected to these two networks during a few milliseconds, to REGISTER, REINVITE and quickly synchronize the communication via the se- cond interface. The IMS and PJSIP must be modified to be able to manage two connections with the same device. Mobility Management Implementation (Figure 2). The chosen solution that was implemented for mobility management was to incorporate a second entry proxy to the IMS. This proxy allows another connection using a second network between the IMS and the second network interface of the device. One was used by the client through its 3G interface, and the other one was used by the WiFi interface. Figure 2. Mobility management with IMS 2 of 8 Mobility Calling Process. A new connection signal was added to PJSIP. This signal is a “re-invite” (REINVITE) message sent by the second interface. This message specifies in its header that it must be routed on the first PCSCF proxy via the second PCSCF proxy. Thus, the first proxy understanding that this device is asking for mobility can duplicate the commu- nication. This was achieved by sending packets on both network interfaces. Both connections are kept active during a few milliseconds, while some packets are transiting to make sure that the new connection is stable. After ten RTP packets, the new connection is considered stable if these packets are well received. The first connection is then closed. 1.3 Setup Routers. In order to have a fully functional environment to test mobility, DDWRT [4], an open-source Unix-based firm- ware was installed on both routers. This Operating System (OS) allows very powerful functionalities for debugging and managing routes with classical Unix commands. Testing. The first important step is to know if the environment is working without mobility. PJSUA was compiled under MacOS 10.6.6 and under Ubuntu 10.04. A call was initialized between two UNIX OS based computers. Patching. The patch provided is working for PJSIP 1.6. After applying the patch to the 1.6 version, compiling PJSUA under MacOS 10.6.6 was no longer possible due to compilation errors. Ubuntu was used for the next testing process. First Results (Figure 3). The initial context is that computers are running the previously patched PJSUA under Ubuntu 10.04. The caller makes a call to the second computer via PCSCF1 using a given network interface (eth0). During the communication a REGISTER and REINVITE signal are sent to PCSCF2 through a second network interface (eth1). Con- sequently, after a few milliseconds the communication switches to the second interface (eth1). All the traffic is monitored with a traffic analyzer to log the mobility management and prove that mobility from one interface to another is working. Figure 3. Wireskark capture - Mobility with test2 (192.168.0.9 then 172.18.1.217) calling test user (172.18.1.6) As expected, the first interface of test2 subscriber registers itself in the IMS then calls the test correspondent. An invite packet is sent and the communication is established once test picks up. RTP packets are exchanged (in Figure 5 only SIP packets are filtered). Then, the second interface of test2 registers itself into the IMS. The two interfaces receive RTP pack- ets during 10 RTP packets (few milliseconds). Then the first connection is closed and only the second connection remains active. 2 Migration on Smartphone This project aims to develop an application on smartphones to manage mobility as the one running on UNIX. To implement this functionality, the project was split up in two parts: one for iOS and one for Android. 3 of 8 2.1 Investigation At the beginning of the project, studies about IMS, SIP/RTP and VoIP were done to understand the context of this project. This investigation was needed to understand how a VoIP application works, and how it can be modified for mobility. Stud- ies on PJSIP were also done to understand how the mobility management was implemented for the PJSUA UNIX applica- tion. Devices. Some tests were performed on the iPhone 3GS and on the iPhone 4 to know if managing mobility can work on them. Android devices such as the Samsung GALAXY Tab and the Samsung GALAXY S were also tested. These tests are explained later on this report. Application Choice. Patching an existing application that uses PJLIB with mobility enhance mobility management imple- mentation. It has been previously demonstrated that PJSUA works with PJLIB patched. Thus, a VoIP application for each operating system (Android and iOS) using PJSIP needs to be found. iPJSUA is a port of PJSUA for iOS, and CSipSimple is the one for Android. PJSIP is directly included in IPJSUA whereas CSipSimple belongs to another project which is based on PJSIP. The two screenshots below (Figure 4) show a part of the GUI of both applications. Figure 4. CSipSimple running on Android (left) iPJSUA running on an iPhone 3GS (right) Application Compilation. CSipSimple can be compiled and runs on the Android emulator included in the Android SDK; PJLIB can also be compiled and integrated to CSipSimple. The latest version of this application is working with PJLIB 1.8. On the iOS side, jailbroken iPhones are required. This allows any compiled application to be brought on real devices and not only on the Xcode provided iPhone simulator. At least, iPJSUA was running on both the Xcode simulator and iPhones. Application Testing. These applications were tested without mobility management. Even after their configuration, some problems were still remaining such as the RTP communication, which is unidirectional. After some research into the source code of these applications, it seems RTP packets should be sent. Thanks to a Man In The Middle (MITM) attack between the client (iPhone 3GS in communication) and the wireless Access Point (AP) on which it was connected, it was discovered using Wireshark that the router was dropping every RTP packet sent by the iPhone. Indeed, this problem was coming from route tables of the router. Its routes were fixed, and both CSipSimple and iPJSUA were working well. 4 of 8 2.2 From PJSIP 1.6 to PJSIP 1.8.10 Patched with Mobility Management PJLIB is used by CSipSimple and iPJSUA. Unfortunately, CSipSimple requires PJLIB 1.8.10 to work and iPJSUA is not yet implemented in PJLIB 1.6.