Fully Mobile Telephony Using VoIP Computer Software

Transcription

1 Fully Mobile Telephony Using VoIP Computer Software Tyler Ross, Habib Hamam, Yassine Bouslimani Université de Moncton, Moncton, NB, Canada Abstract Our global objective is to profit from the technology offered by the computer and/or Internet without being constrained by sitting in front of a computer. As an example of application, we present a method to use Voice over IP (VoIP) computer software remotely. This method targets mainly the population with reduced mobility or the population unfamiliar with computers, who may have difficulty using this type of software on the computer itself. This design allows for the use of a telephone keypad and headset with a microphone wirelessly, away from the computer. The system attempts to mimic the same kind of interface provided by telephones, with the same type of keypad, in an effort to maximize convenience, and reduce the amount of difficulty that someone with reduced mobility may have in using the system. We will describe the implementation used, present some results on how well the system works and some possibilities for the future. Index Terms Aids for the handicapped, Computer interfaces, User interfaces, Wireless communications, Reduced mobility, Telephony. wireless receiver for the keypad can connect to the Universal Serial Bus (USB) port of the computer. This simplifies installation and configuration of the device. Also, many wireless headsets have USB connectors that connect directly to a computer, or use Bluetooth technology [2]. In the latter case, a relatively inexpensive USB adapter can be purchased, if the computer does not natively support Bluetooth. The choice of the headset itself is left to the user, to suit his or her individual needs. This article includes a brief summary of the main motivations behind the proposed solution. We then describe the solution in terms of the hardware and software implementation used. Finally, the observed results and possible improvements to the design are presented. I. INTRODUCTION Stated in the most general terms, we aim to profit from the technology and tools offered by the computer (PC) and/or Internet without being constrained by sitting in front of a PC. In this article, we intend to present a way for people with particular constraints (i.e. reduced mobility, unfamiliarity with PCs) to be able to utilize Voice over IP (VoIP : [1]) computer software, such as the popular Skype application using a familiar telephone keypad and a headset, while minimizing the use of a mouse and keyboard. This reduced required use of the keyboard and mouse is a great advantage for populations having difficulty using a computer, for medical or other reasons. To complement the keypad for interfacing with the VoIP software is a wireless headset. Since wireless headsets are already fairly commonplace and have proven themselves to work well, it makes sense to use one as part of the solution. A headset also frees a person s hands, which is convenient and may also be essential for populations with reduced mobility or a disability or for someone who wants to be mobile in a limited area (at home, in a work building, ). One of the main objectives is to make the interface as simple as possible for the user. Thus, the headset and the keypad are wirelessly connected to the computer. This offers full mobility for the user without being constrained by wires or cables and by sitting in front of the PC. The Fig. 1. Diagram showing the basic system II. APPLICATIONS There are several possible applications of our solution. One example, mentioned above, allows people with a reduced level of mobility to take advantage of the benefits of VoIP software, like that offered by Skype [3]. Another possible application would be as a cordless VoIP phone. Similar to the cordless phones used for traditional landline telephones, it could be used to make calls over the internet.

2 Another application could be as an emergency help button, where someone who has injured oneself and is unable to move can make a call for help by pushing just one button. A call could then be made automatically to a caregiver, letting him know that the person may be in distress. Conceivably, using a wireless standard such as the IEEE (ZigBee [4]) or IEEE (Wi-Fi [5]), one could have one central server to receive and make telephone calls, in a short-range wireless network, similar to a small-scale cellular network. Users could connect to a central server which would manage the sending and receiving of calls. changed to avoid such interference. In the 2.4 GHz band, there are 16 channels available for ZigBee communications, each with a width of 3 MHz. III. PROPOSED METHOD The method we propose is to use a keypad and headset, and use a wireless link to transmit the user s voice and button presses to the VoIP software running on the user s computer (Fig. 1). The host application running on the computer in turn interfaces with the VoIP software and executes the necessary commands. The user only needs to dial the destination phone number on the wireless keypad and the software running on the computer will react as would be expected from a regular telephone. An attached Liquid Crystal Display (LCD) screen could give feedback to the user so that, for example, they may verify that they did not make a mistake when entering the phone number. If a user does make a mistake, then they can clear the number they were dialing. In this article, we propose two possible configurations to enable a user to be fully mobile while remotely performing a phone call through a computer by using the VoIP technology. The first involves the headset being connected to the keypad (Fig. 2). There, the audio signal from the headset s microphone and the signal from the keypad itself are combined and transmitted towards the computer. Likewise, in the opposite direction, the signals received from the computer must be separated. In the case of our implementation, we have elected to use ZigBee transceivers to send and receive data. This allows for the option to expand the system into a network of users since the ZigBee specification was designed to be used with self-organizing ad-hoc wireless networks. The ZigBee specification also provides reliable data transfer, which eliminates the possibility of invalid button presses being sent or received. In most countries, ZigBee utilizes the industrial, scientific and medical (ISM) bands; 2.4 GHz in most areas. Since there are already many devices that operate in this band (Wi-Fi, Bluetooth, many cordless telephones, etc.), there may be interference between ZigBee communications and these other technologies. However, the channel used for ZigBee communications can be Fig. 2. Diagram showing the first considered configuration The second configuration involves using a headset which is kept completely separate from the keypad and its connections, from the user to the computer (Fig. 3). This second configuration has several advantages, such as the ability to leave the keypad behind and wear only the headset while speaking to another person. A second advantage consists of the obvious simplification of the design and implementation. As a third advantage, one can mention the extent to which the users are able to customize the solution to their needs. The ability of the users to select any headsets that are comfortable and remain inside their preferred price range while being assured that they will work with the system without modification is a great asset. This also allows for the individual parts to be swapped, in case of defect or age without replacing the entire system. One advantage of the first configuration is that it reduces the number of necessary free ports on the computer. However, nearly all new wireless headsets use

3 or can be adapted to use USB connections, and computers normally have several USB ports, with USB hubs also being fairly inexpensive. Therefore, the second configuration, needing one extra USB port on the computer, is not especially inconvenient. Fig. 3. Diagram showing the second considered configuration IV. HARDWARE IMPLEMENTATION The proposed solution uses a keypad to receive the user s input and can use an LCD screen to display any feedback. The wireless headset will be used as-is, without requiring any kind of modification. The keypad is connected to a microcontroller-based circuit which is responsible for scanning the keypad. While either scanning method would work, the microcontroller scans the keypad by rows. This microcontroller is also connected to a wireless transmitter, which alerts the circuit connected to the computer of any buttons that the user may have pressed. Connected to the computer is a second microcontroller, which receives messages using a wireless receiver, and forwards them to the computer over a USB connection. The USB driver for the device is included in the firmware we developed for the microcontroller, and so does not require any additional components. The keypad currently being used is a standard 3x4, series 96 keypad by Grayhill. This allows for all the standard buttons on a telephone, although a larger keypad could be used, to allow for more buttons such as extra speed dial buttons. Like many keypads, it is connected as a matrix, and is scanned either by row or column. As previously mentioned, the keypad is connected to a microcontroller circuit. The microcontroller used is the ATMEGA8-16 from Atmel. This 8-bit RISC microcontroller sports a large number of I/O ports, a fairly large flash and good performance. Coupled with its low cost, it is quite sufficient for our purposes. The second microcontroller, connected to the computer, is also an ATMEGA8-16. This microcontroller s purpose is essentially to take input from the connected wireless receiver and hold the data until it is requested from the computer. The USB driver is based on the AVR-USB firmware-only driver from Objective Development Software GmbH [6]. Its only requirement is a 12MHz crystal, used as the clock source, which connects directly to the microcontroller. All other functionality is built into the microcontroller s program. Using this driver, the device conforms to the USB 1.1 standard as a low-speed device. It does not, however, qualify as a Human Interface Device and therefore requires a software driver to be installed on the host computer. This will be discussed further in section V. The AVR-USB driver used firmware implementation of a USB 1.1 low-speed device. It runs on any AVR microcontroller with at least 2 kilobytes of flash memory, 128 bytes of RAM, and a 12MHz clock. It also requires an edge-triggered interrupt [7]. Using this driver, one is able to create compliant and flexible USB devices without the need for extra hardware. The driver is written in C and thus allows for relatively simple customization and implementation. Objective Development has released this driver as free software. The second microcontroller will store up to eight button presses, so as to avoid losing button presses should there be an unexpected delay in the computer requesting a USB control transfer. This buffer should be sufficiently large, given that these control transfer requests are sent every 250 ms by the host application. It is unlikely that more than eight valid button presses will be made inside this interval. The buffer holds eight values because the largest amount of data that can be transferred during one control transfer for a low-speed USB device is eight bytes. Limiting the buffer to this size simplifies the firmware implementation, while offering a large enough buffer. The wireless module used is the MaxStream XBee ZigBee RF Module. This IEEE compliant

4 module allows for two-way communications between the keypad unit and the computer, at speeds up to 250 kbit/s. This should be enough bandwidth for the traffic that they keypad generates as well as a compressed audio stream, if it is implemented. The ZigBee specification was designed specifically for ad-hoc wireless networks. Therefore, we leave open the option of having multiple users. number in the VoIP software. The second mode allows for the user to press one button, and the host application will dial a preset number and optionally play a prerecorded message. This could be of some benefit to someone with reduced mobility who may have fallen and urgently requires assistance. V. SOFTWARE IMPLEMENTATION The role of the software component is twofold. First, it must detect and poll the hardware device for pressed buttons and second, it must interface and carry out the user s commands in a chosen VoIP application, such as Skype. We will discuss software implementation starting with the hardware interface and ending with interface to the chosen VoIP software. As mentioned in section IV, the USB device used is not considered to be a Human Interface Device. Human Interface Devices, such as mice, keyboards and joysticks often do not need to include a driver because one is normally included with the user s operating system. As a driver, we have elected to use the free libusb library [8], which allows us to avoid writing a kernel-mode driver for use under Windows. The library also has a common interface between operating systems, such as Linux or MacOS, if portability is desired. libusb provides a generic kernel-mode driver under Windows, which provides the low-level communications between the USB device and the operating system. libusb contains generic functions for sending and receiving data, enumerating devices, getting information about the USB buses and ports, claiming a USB device interface, etc. The library then exposes simple mechanisms to allow the control of USB devices connected to the system. It allows for interrupt, control and bulk transfers over the bus, though our application only performs control transfers. The control application we have developed also supports a device connected to a serial port or a parallel port. These ports are considered by many to be legacy ports however, and are increasingly being left off of new computers. When configured to use USB, the application will scan all connected USB devices every few seconds to determine whether our device has been connected. If it is connected, the device will be queried four times per second, to determine if any input has been received from the user. If the host application does detect a pressed button, it can behave in two ways. First, it can behave like a normal telephone, and treat the pushed button as a number in a telephone number. Once the user has entered a complete ten digit telephone number (3 digits for area code + 7 digits according to North American format), it will dial the Fig. 4. Diagram showing the two modes in which the software can operate To implement a working system, it was necessary to choose a VoIP application. We have chosen Skype, a very popular program for sending and receiving telephone calls on a computer. Currently, Skype provides an application programming interface (API) to allow other programs to control it. At this time, their API does not allow another program to send audio data directly. As a result, to allow for the possibility that a user may wish to use our host application to send a pre-recorded message, the host application is able to manipulate the Windows Mixer (usually accessed through the Windows Volume Control application) to redirect the WaveOut output so that it is treated as an input and can be captured by Skype. With this done, all that is left for the host application to do is play the sound file that the user had previously recorded. The host application also detects whether Skype is running and connected. If it is not, when the user dials a number or presses a speed dial button, the host application will attempt to start Skype, connect, and then proceed to dial the requested telephone number. While the host application is running, its configuration can be modified, to change the different speed dial

5 options, or to switch to a different interface (among USB, parallel, and serial). The host application will detect any modifications made to its configuration file, and will reload it at that time. The host application uses a simple XML file for configuration. This allows for easy modification of the file and simplifies the addition of new configuration directives. Figure 4 summarizes the working principle of the software. When the software receives notification that a button has been pressed, it checks whether the button is a speed dial button, or a regular number. If it receives a complete telephone number, it will instruct Skype to dial the telephone number. It then leaves the user connected in the call. The user may end the call by pressing a button on the keypad. If a speed dial button was pressed, the software will dial the preconfigured telephone number. If a message was not selected to play, it will leave the user connected in the call, as before. If a pre-recorded message was selected, it will redirect the computer s WaveOut sound output to the Skype s input, using the Windows Mixer and then play the message. Afterwards, it will terminate the call automatically. VI. TEST RESULTS We have implemented and tested both software modes described in section V, by using the keypad connected to one microcontroller and the USB interface to the computer. We have also tested the host application while using the keypad connected through the parallel port interface. In both cases, we were able to connect to the host application successfully. The host application was also able to start Skype if it was not running, connect, and call the telephone number that the user had entered. The speed dial function has also been tested successfully. While testing the speed dial options, one small problem, concerning the playback volume, arises. When a recorded message was selected to be played automatically, the volume of the audio message had to be reduced by approximately 50% in order for it to be understood, even though the playback sounded quite normal on the computer that was sending the message. There are several ways to remedy this problem. First, the user could reduce the volume when recording the message. Second, the volume could be reduced automatically when playing the message. This would be the preferred method, since it would require no action on the user s part. This is extremely important, given that our solution targets those who may be unfamiliar with computers and who have difficulty using them, because of reduced mobility, disability, etc. We have also tested the wireless connection provided by the ZigBee modules. The wireless connection worked extremely well. The effectiveness and reliability of the wireless system was indistinguishable from that of the fully wired system. VII. CONCLUSION & PERSPECTIVES In this article, we have discussed a method that would allow people to remotely use VoIP software, such as Skype. We implemented a system including a hardware as well as a software part. For each of the two parts, we advanced two possible solutions. Descriptions of the hardware used, as well as details of the software implementation have been given. The system enables users to be full mobile while performing phone calls through an existing VoIP software application. Possible applications of the method have been reviewed. Further possibilities for this project include the integration of the keypad and microphone into one, more compact unit, so that it is easier for the user to handle. Another possibility is to explore further the integration of the microphone into the same circuit as the keypad and use only one wireless link. ACKNOWLEDGEMENT The authors wish to acknowledge the technical assistance of Jonathan Blanchard and the financial support of the Natural Sciences and Engineering Research Council of Canada. REFERENCES [1] VoIP converts the voice signal from your telephone into a digital signal that travels over the Internet: [2] [3] [4] ZigBee operates in the industrial, scientific and medical (ISM) radio bands; 868 MHz in Europe, 915 MHz in the USA and 2.4 GHz in most jurisdictions worldwide: [5] IEEE , the Wi-Fi standard, denotes a set of Wireless LAN/WLAN standards developed by working group 11 of the IEEE LAN/MAN Standards Committee (IEEE 802): [6] [7] [8] J. Erdfelt libusb Developers Guide :