Group Voice Mixer

Full text

(1)2010:005 CIV. MASTER'S THESIS. Group Voice Mixer. Andreas Berglund. Luleå University of Technology MSc Programmes in Engineering Computer Science and Engineering Department of Computer Science and Electrical Engineering Division of Computer Communication 2010:005 CIV - ISSN: 1402-1617 - ISRN: LTU-EX--10/005--SE.

(2) L ULEÅ U NIVERSITY OF T ECHNOLOGY S WEDEN. Group Voice Mixer. Author: Andreas B ERGLUND. Supervisors: John S ANDBERG Magnus N ILSSON -M ÄKI Kåre S YNNES. January 19, 2010.

(3) Abstract The purpose of this study was to investigate how to construct an Application Programming Interface (API) facilitating developers with including conferencing functionality into applications. The API should furthermore include a method of mixing audio, based on the location of the conference participants. The study was commissioned by Ericsson Research. A qualitative research methodology was utilized in this study. The research data was provided in part from consultations with two supervisors assigned to this study by Ericsson Research. The basic operatives needed in the API were provided by these deliberations. The result of this study is a Java platform Micro Edition (Java ME) API which provides a developer with the means to construct a conferencing application or add conferencing functionality to an existing application. A method is included to allow audio being mixed, based on the location of the participants in a conference. The API is aimed towards mobile phone applications, but can be used on any platform supporting Java ME. The author recommends the result of this study being used when wanting to implement basic conferencing operations in a project of small scale. If the project is of a larger scale or intended as a commercial product, it is recommended to use either a more seasoned API or extend the API presented in this study with more functionality, security and robustness..

(4) Preface The work described in this report was made as a Master Thesis in ComputerScience on behalf of Systemteknik (SYS) at Luleå University of Technology (LTU). The Thesis was written at Ericsson Research, Luleå during summer/autumn 2009. This work is intended to be distributed as a location based group voice mixing API on Ericsson labs (https://labs.ericsson.com/). The instructor assigned by LTU to oversee this Thesis was Kåre Synnes. A special thank you is extended to John Sandberg and Magnus Nilsson-Mäki who were assigned as mentors at Ericsson Research for the purpose of this Thesis. Their directions and invaluable input have greatly contributed towards this Thesis. A thank you is also extended Tor Björn Minde at Ericsson Research for granting me the opportunity to work on this Thesis. Another big thank you goes out to all friends who have proofread this report and supported me during the course of this project..

(5) Contents 1 Introduction 1.1 Problem statement 1.2 Purpose . . . . . . 1.3 Delimitations . . . 1.4 Definition of terms. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. 2 Theoretical framework 2.1 Java[6, 7] . . . . . . . . . . . . . . . . . . . 2.2 Java Platform, Micro Edition[8, 9, 10] . . . . 2.3 Private Branch eXchange[11] . . . . . . . . 2.4 Asterisk-Java manager API[13] . . . . . . . 2.5 Conference bridge . . . . . . . . . . . . . . 2.6 Voice over Internet Protocol[15, 16] . . . . . 2.6.1 Session Initiation Protocol[17] . . . . 2.6.2 Real-time Transport Protocol[18] . . 2.6.3 Inter Asterisk eXchange Protocol[20] 2.7 Ericsson Labs . . . . . . . . . . . . . . . . .. . . . .. . . . . . . . . . .. . . . .. . . . . . . . . . .. . . . .. . . . . . . . . . .. . . . .. . . . . . . . . . .. . . . .. . . . . . . . . . .. . . . .. . . . . . . . . . .. . . . .. . . . . . . . . . .. . . . .. . . . . . . . . . .. . . . .. . . . . . . . . . .. . . . .. 1 1 2 3 4. . . . . . . . . . .. 5 5 5 6 7 7 8 8 9 9 9. 3 Software development 10 3.1 Development Environment . . . . . . . . . . . . . . . . . . . . 10 3.2 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4 Voice Mixer 4.1 Control flow . . . . . . . . 4.2 Server side Configuration 4.3 Asterisk Configuration . . 4.3.1 Extensions[26] . . 4.3.2 IAX[27] . . . . . . 4.4 AppKonference[28] . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. 12 13 14 14 15 16 17.

(6) 4.4.1 Functionality . . . . . . . . . . . . . . . . . . . . . . . 17 4.4.2 Commands . . . . . . . . . . . . . . . . . . . . . . . . 17 4.4.3 Events . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5 API 5.1 Platform . . . . . . . 5.2 Networking . . . . . 5.2.1 Sender . . . 5.2.2 Receiver . . 5.2.3 KeepAlive . . 5.3 platformRequest[31] 5.4 ConferenceClient . . 5.5 API restrictions . . . 5.6 Obfuscation . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. 18 18 18 19 19 19 20 20 21 22. 6 Application. 23. 7 Conclusions 7.1 Evaluation . . . . . . . 7.1.1 Phase 1 . . . . 7.1.2 Phase 2 . . . . 7.1.3 Phase 3 . . . . 7.1.4 Phase 4 . . . . 7.2 Discussion . . . . . . 7.3 Future improvements .. 29 29 29 29 30 30 32 33. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. A Important methods 38 A.1 Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 A.2 General commands . . . . . . . . . . . . . . . . . . . . . . . 39 A.3 Moderator commands . . . . . . . . . . . . . . . . . . . . . . 40 B Example Application. 41.

(7) Chapter 1. Introduction 1.1. Problem statement. In recent times, teleconferencing has become a more and more common way of communicating[1]. Especially within the business sector. Teleconferencing allows for people located in different rooms, buildings, cities and countries to share information with each other in real-time. A common example is having phone calls with multiple people, speaking in the same session or for one person to broadcast his or her voice to many. This type of communication is commonly used with an assortment of hardware specifically designed for bridging calls between different parties. For private persons, outside the world of business and corporations, solutions usable with mobile phones are more sparse. There are few applications on the market aimed at regular customers and even fewer supporting advanced voice mixing features. When using a mobile phone, a delay over the Public Switched Telephone Network (PSTN) is to be expected. This fact is not very noticeable unless you are in the same physical room as the person or persons you are conversing with. Since it is common to have several people engaged in a conference in the same conference room, a feature compensating this would be desirable. An implementation counteracting this would allow the people in the same room to select not to hear each other on the line, as they will hear each other talking before the audio arrives in the conference. That is, a way to selectively mix audio based on location, is an example of an advanced voice mixing feature relevant to a conferencing application.. 1.

(8) 1.2. Purpose. One existing application for teleconferencing is the Meeting Mobilizer. It is a vertically integrated group voice conference application for mobile phones aimed at enterprise use. Since the voice mixer and the application is integrated in this vertical solution, another application in need of a voice mixer would be unable to utilize the one from the Meeting Mobilizer. The facts laid out in the problem statement provides the basic outline of this thesis. The aim of this thesis is to study how to make a horizontal solution of a conference application. Horizontal in this meaning stands for having an Application Programming Interface (API) providing the conferencing functionality while being separated from the actual application. The reason for this is that the conferencing functionality of the API should not be tied down to the implementation of the application, but be reusable for any application in need of the functionality provided by it. Therefore an API should firstly be made available for a group voice mixer. This API will provide the means to easily make a conferencing application with voice mixing enabled or add group audio to an existing application. Thereafter a group voice chat application should be implemented for a mobile phone using the API, to show an example of how the API can be used. This application will be based on an application called Ericsson Geo chat, developed as another Master thesis at Ericsson Research. Ericsson Figure 1.1: Describes the difGeo Chat allows for people to chat with ference between a horizontal each other over the phone based on ei- and a vertical implementation ther the physical or virtual location of the of an application. To the left user. These locations are depicted as red is a horizontal solution, with squares on a map, which the user may cre- the conferencing functionality ate anywhere in the world. If the phone in an API, separated from the running this application is equipped with a application. To the right is a GPS, a user physically standing in the area vertical solution with all funcdepicted by the square can chat with peo- tionality integrated in the apple virtually entering that same “chat room” plication. on the mobile phone. 2.

(9) 1.3. Delimitations. It is easy to find a number of applications providing conferencing functionality, such as Cisco Telepresence[2], AT&T Telepresence[3] and many more[4, 5]. Many of them are equipped with advanced features supporting hundreds of parameters and customizable settings. The purpose of this Thesis is not to try and outperform complex solutions provided by big companies with full time staff working on improving their products. The aim of this thesis project is instead to make a user friendly high level API, making it easy for anyone with a basic knowledge of programming to include conferencing functionality into an application. The API will cover the basic needs of a conferencing application as well as providing some more advanced features, such as location based voice mixing.. Figure 1.2: The users at location x both send their audio to the user at location y, but not to each other. The user at location y sends its audio to both users at location x By location based voice mixing it is meant that it’s possible to select which conference participants to receive audio from, based on location. This makes it possible for a member of the conference to choose not to receive audio from other members in the vicinity. This can be desirable since being close to another member ensures that audio will be received without the help of a conference. It follows that without this feature the same audio will be received twice, first physically and then after a delay in the conference. Location based audio mixing is designed to prevent this.. 3.

(10) 1.4. Definition of terms. API Application Programming Interface CLDC Connected Limited Device Configuration GPS Global Positioning System GSM Global System for Mobile communications IAX Inter-Asterisk eXchange IP Internet Protocol J2ME Java 2 Micro Edition (old name for Java ME) Java ME Java Platform Micro Edition JVM Java Virtual Machine MIDP Mobile Information Device Platform NAT Network Address Translation PBX Private Branch Exchange PSTN Public Switched Telephone Network RAD Rapid Application Development RTP Real-time Transport Protocol SIP Session Initiation Protocol TCP Transmission Control Protocol UDP User Datagram Protocol VoIP Voice over Internet Protocol WTK Wireless ToolKit. 4.

(11) Chapter 2. Theoretical framework This chapter presents the underlying concepts and technologies that have been researched and used in the development of this project.. 2.1. Java[6, 7]. Java is an object-oriented programming language. By object-oriented it is meant that almost everything in Java can be seen as an object. The exception to this rule are the primitive data types such as characters, booleans, ordinal and real numbers. These types are not objects for performance reasons and are stored in fields and on the stack, instead of the heap as object normally are. An attractive feature of the Java programming language is the fact that it does not compile to native machine code, but instead to “byte code” instructions for the Java Virtual Machine (JVM). The benefit of bytecode is that it is architecture independent. So the same compiled byte code will run unmodified on any platform that supports Java. This is great for portability. Another attractive feature of Java is it’s rich standard library. Hundreds of classes already exist to provide common functionality such as networking and threading.. 2.2. Java Platform, Micro Edition[8, 9, 10]. Previously known and commonly referred to as Java 2 Micro Edition (J2ME), Java ME is a Java platform designed for mobile devices and embedded systems. Most mobile phones sold today support Java applications, though some may restrict which applications are usable to those approved by the 5.

(12) carrier. Java ME devices implement a Profile which is a subset of a Configuration. Mobile Information Device Platform 2.0 (MIDP 2.0) is a Profile designed for mobile phones. MIDP is a subset of Connected Limited Device Configuration (CLDC) which contains a cut-down version of the Java Virtual Machine (JVM) and a strict subset of Java class libraries. An application written for the MIDP is called a MIDlet.. 2.3. Private Branch eXchange[11]. It was decided for this project that all internal call handling of the conferences were to be made through an Asterisk[12], which is a software implementation of a PBX. A Private Branch eXchange (PBX) is a telephone exchange not operated by common carriers or telephone companies. A PBX allows attached telephones to make calls to one another and to connect to other telephone services including the Public Switched Telephone Network (PSTN) and Voice over Internet Protocol (VoIP) services. They are commonly used to make connections within private businesses. Instead of paying a regular telephone carrier for placing calls within the company, a PBX can be used to handle all internal calls, without the need to send them over the PSTN. Calls outside the company are then routed to an external carrier and proceed as normal. Asterisk functions in a modular form, utilizing different APIs to abstract between its central PBX core system and the different technologies existing (or in development) in the telephone industry. This means that the Asterisk core does not need to worry about applications called, codecs used and the type of connection a caller is using. To allow outside clients to interact with the PBX, Asterisk provides an interface called the Asterisk Manager Interface (AMI). The asterisk manager interface allows for a client to connect to the Asterisk over a TCP/IP connection. Thereafter the client can send commands to, and receive events from the PBX.. 6.

(13) 2.4. Asterisk-Java manager API[13]. Asterisk-Java is a free Java library containing a set of Java classes which allow an application to interact with Asterisk servers. At the beginning of the project, it was unclear whether or not this library could be used due to licensing issues. This resulted in a Java interface being constructed from scratch for interactions with the Asterisk. Later, when it became clear that this library could be used in the voice mixer, the newly constructed Asterisk communication API was abandoned for the more mature Asterisk-Java API.. 2.5. Conference bridge. Asterisk provide by default a plug-in called MeetMe[14] which allows a user to create numerically named conferences. A limitation of this plug-in is that it requires a Zaptel timer to work. To get this timer the Asterisk server needs either to install Digium hardware or optionally a dummy driver to emulate the timing functionality. This option is only available on Linux systems. This problem was initially solved by installing ztdummy on the Asterisk. ztdummy is a Linux kernel module which uses the internal kernel timer in order to provide the Asterisk with an emulated Zaptel timer. MeetMe turned out to contain means to provide almost all functionality desirable by the API, but unfortunately failed on one vital point. It provides no support at all for the location based voice mixing functionality which is the key feature of this API. Furthermore, all the audio mixing of the plug-in was done externally by Zaptel which means there’s no way of finding out how it was done in order to modify it. Even if the mixing algorithm had been found out, a problem would still remain. The fact that the plug-in isn’t open source would prevent the modifications needed to enhance the plug-in to fulfill the needs of this API. Due to failure in finding a sufficient conference plug-in replacement, development began of a separate conference server in Java. The idea was that the server should locally run dummy SIP clients representing the clients connecting over the PSTN. All clients would connect to its own dummy client on the server and as far as it knew, have a two way conversation. The dummy client would then be connected to a conference with other dummy clients. All the voice channels would thus lie on the server, mixed manually by the server software. This would allow for greater control of audio chan7.

(14) nels and connections, though provide a heavier load on the server. Eventually, an alternative conference plug-in by the name of AppKonference was found and the SIP server/client implementation could be abandoned in favor of this. This plug-in provides about the same functionality as MeetMe but is sparsely documented and just like MeetMe lacks built in support for the sought after advanced voice mixing feature. The reason that the choice of conference bridge for use by this API fell on AppKonference was the fact that it was open source, providing all source code free for modification and redistribution. In addition to being open source, AppKonference provides its own timing, requiring no additional modules or hardware. Being open source meant that any functionality needed apart from the existing features could be implemented in the source code and recompiled for use by the Asterisk. Since the plug-in is used by the Asterisk, on the server side of the conferencing system, the open source license does not interfere with this project being closed source.. 2.6. Voice over Internet Protocol[15, 16]. Voice over Internet Protocol (VoIP) defines technologies for the transmission of voice through package-switched networks such as the Internet. VoIP systems carry telephony signals in a digital format, converted from the analog voice signal. The digital signal is typically reduced in data rate through the use of speech data compression techniques. After encapsulating the signal into Internet Protocol (IP) packets, the data-packets are transmitted over the Internet. When the packets are received at the other end, the process is reversed.. 2.6.1. Session Initiation Protocol[17]. The Session Initiation Protocol (SIP), is a signaling protocol used to set up, modify and tear down sessions, when used to control VoIP. A session being an inter-participant exchange of data such as media streams. SIP is an Application Layer protocol designed to be independent of the underlying transport layer. It is most typically used on top of Transmission Control Protocol (TCP) or User Datagram Protocol (UDP). SIP does not carry the actual media communications, which is normally carried over Real-time Transport Protocol (RTP). A problem with SIP concerns routing when a Network Address Translator (NAT) is involved. The problem does not actually 8.

(15) lie with SIP, but with the RTP connection that is being set up through SIP. SIP identifies the RTP ports of both ends of a session to the other part, but if a NAT is involved, the actual port opened externally might be different. This will mean that the clients don’t know which port to actually connect to.. 2.6.2. Real-time Transport Protocol[18]. The Real-time Transport Protocol (RTP) defines a standardized packet format for end-to-end delivery of data with real-time properties, such as audio and video, over the Internet. Call setup and tear-down for VoIP applications is usually performed by either SIP or H.323[19] protocols. Since applications using RTP are less sensitive to packet loss, but typically very sensitive to delays, RTP is most commonly used together with UDP.. 2.6.3. Inter Asterisk eXchange Protocol[20]. The Inter Asterisk eXchange revision 2 (IAX) protocol is used as an alternative to the more commonly supported SIP and H.323 connecting devices. IAX2 is a VoIP protocol which carries both signaling and media on the same port (4569). This makes it easy for IAX2 to traverse NATs and firewalls, giving it a huge advantage over SIP in this regard. Signaling and media flow is multiplexed in binary form on a single UDP data stream between two computers. One of the major advantages of IAX2 over SIP for VoIP traffic is the IAX2 jitter buffer which significantly improves audio quality over non-ideal links such as ASDL. Another major selling point for IAX2 when used for VoIP transmissions is its support for trunking. Trunking allows data from multiple calls to be merged into one single stream of packets sent between two endpoints reducing the IP overhead without creating additional latency. This stems from the fact that IP headers use a large percentage of the bandwidth in VoIP transmissions.. 2.7. Ericsson Labs. Ericsson Labs[21] is a website hosted by Ericsson. The site contains a variety of APIs, resources and applications produced by Ericsson. The purpose of the site is to help the community of developers by providing useful resources and ways of contacting experts from different fields. The intention is that the API produced in this project will be available to the public through Ericsson Labs. 9.

(16) Chapter 3. Software development 3.1. Development Environment. The voice mixer and the API was written using a version of Eclipse[22] 3.1 extended with Ericsson specific plug-ins. Eclipse is a software development environment commonly used to write Java programs, but is not limited to this. Eclipse is comprised of, apart from the Interactive Development Environment (IDE) in which code is written, an extensive plug-in system. There are plug-ins for this application providing support for most popular programming languages. Sony Ericsson SDK[23] 2.5.0.3 for Java ME was used when testing the basic features of the API. This package is built on top of the Java Wireless ToolKit (WTK) which has the ability to emulate mobile phones. Java WTK is a toolbox used when developing wireless applications based on Java ME, CLDC and MIDP. Since Java WTK does not provide support for emulating native functions in mobile phones, the call functionality of the API was tested by writing small test applications which were then loaded into mobile phones. Mainly Sony Ericsson K810i mobile phones were used, but also a K800i and a K850i. The conference plug-in AppKonference (written in C) was modified using the text editor Vim[24]. Vim was also used to write the configuration files of the Asterisk. Vim is a highly configurable text editor for UNIX[25] systems complete with syntax highlighting and hotkeys for an abundance of commands.. 10.

(17) 3.2. Methodology. When choosing which software development methodology to adopt for this project, the following facts were taken into account: • The size of the project is small consisting of one developer. Most methodologies rely on having development teams. • Demands and requirements are stated by several, to some degree independent contractors and are likely to be changing during the course of the project. • The project is to be developed in Java, an object-oriented programming language. Object-oriented languages are perfect for reusing written code in the form of classes, methods and interfaces. • A server-client model is to be used, meaning that changes on one side likely need to be reflected on the other side should they concern the signaling protocol implemented between the two. These facts in hand, a customized version of Rapid Application Development (RAD) was chosen. RAD is a methodology with emphasis on iterative development. The development process is divided into several cycles. In the beginning a functioning prototype is constructed and then extended iteratively in each new cycle. Functionality is thus added as the project progresses and when new requirements are added they can be scheduled for implementation in the next available cycle. The number of cycles were not decided beforehand for this project and neither were their contents.. 11.

(18) Chapter 4. Voice Mixer The purpose of the voice mixer is to act as a mediator between the client and the Asterisk. All internal states of conferences and users are stored and controlled by the voice mixer. The voice mixer receives requests sent by clients and converts them into actions either changing states of conferences and users or passing them along to the Asterisk. The voice mixer mediates in the opposite direction as well, using the events sent by the Asterisk either to change internal states of conferences or it can pass them along to affected clients.. Figure 4.1: System overview. 12.

(19) Figure 4.1 provides a simplified picture of how every part of the project is connected. The client has a direct TCP/IP connection to the voice mixer on which it sends actions and receives events. The client is also connected, either directly over the IP layer or in the case of a phone firstly through the Public Switched Telephone Network (PSTN) to the Asterisk. This is the connection that all audio is sent over. Then there is a connection between the voice mixer and the Asterisk where the voice mixer controls the audio channels and makes extensions in the dial plan for clients to call. Behind the Asterisk server lies the conference plug-in doing the actual audio mixing. The voice mixer controls the actions of this plug-in through the Asterisk.. 4.1. Control flow. To understand the control flow, a simple example where a user wishes to create a conference is shown below. The user has already logged in on the voice mixer server and can therefore send actions.. Figure 4.2: createConference(x) control flow. The client begins by sending the action createConferece(x). This tells the voice mixer that the client wishes to create a conference named x. The voice mixer checks if the conference already exist and if it doesn’t, it tells the Asterisk to expect a call from the client, whose MSISDN (telephone number to a mobile phone SIM card) it already knows. The Asterisk is informed that an incoming call from the client should be routed to conference x. The voice mixer then tells the client to call num, which is the number bound to the conference service. The client passes the number along to the native part of the phone, which makes the call. When the client is connected to 13.

(20) the conference the Asterisk notifies the voice mixer which now can update its internal state to reflect this.. 4.2. Server side Configuration. A variety of settings for the voice mixer are stored in the file conference.conf. Examples of settings concerning the server side that can be modified in this file are: address IP address of the Asterisk port port opened for client connections number number to call into the Asterisk manager manager account name on the Asterisk password password for the manager account max_conf_members maximum simultaneous members in a conference max_conf_duration maximum duration of a conference in seconds log name and location of the log file This configuration file is loaded once upon the initialization of the voice mixer, but is written to allow for dynamic loading of settings. This makes it possible to change settings at anytime, even when the voice mixer server is running, having the changes go into effect at once.. 4.3. Asterisk Configuration. This section contains information concerning configurations used on the server side of the conference API. The Asterisk contains several configuration files, but not all of them are important for the scope of this project. The ones listed here are those deemed most relevant to this project. Configuration details are not presented here in depth, just general definitions.. 14.

(21) 4.3.1. Extensions[26]. The Asterisk configuration file “extensions.conf” contains the dial plan for the Private Branch eXchange (PBX). The dial plan defines how incoming and outgoing calls are handled and routed. This is the most important configuration file in the Asterisk PBX as all behavior of connections through the PBX is configured here. Pattern-matching is used to map the dialed extensions into actions performed by the PBX. Such actions include but are not limited to, dialing, voice-mail, playing sound-files, transferring and hang up connections. The dial plan consists of a number of contexts. Each context contains a collection of extensions. Incoming connections are sent to an appropriate context defined either by the dial plan or the external source of the connection. Inside the context, pattern-matching is used to determine which extension or series of extensions the connection will use. The basic way of making it possible for clients to dial in to a conference, is that each client must have a channel on the Asterisk. A channel can be received by registering a SIP client in a configuration file of the Asterisk. This would mean that for every possible user of the conference API, a SIP client must be created beforehand. The user must then register to its SIP client before joining the conference. This is clearly not a viable solution, which is why an alternative solution was constructed. When a client wants to create or join a conference, a series of entries is dynamically added to the Asterisk dial plan by the voice mixer. When the dial plan is set up to handle the client, an event is sent telling the client to call a specified number. This number is through an exterior Asterisk bound to the conferencing Asterisk, so that when the client calls the number, it is forwarded to the conferencing Asterisk and placed in the appropriate series of extensions through mapping of the user name of the client. A simple example of a dial plan entry could look as follows:. [dial-in-conferences] //context <EXTENSION>,1,Ringing //send ringing tone <EXTENSION>,2,Wait,<X> //wait x seconds <EXTENSION>,3,Konference,<CONFERENCE_NAME> // dial conference <EXTENSION>,4,Hangup // hang up connection. 15.

(22) This bit of code tells the Asterisk that any client calling <EXTENSION> should receive a ringing tone in their phone. The pause of <X> seconds will be where the client receives the tone after which it will be placed in conference <CONFERENCE_NAME>. When the conference is over, the connection to the client will be hung up.. 4.3.2. IAX[27]. The Asterisk configuration file “iax.conf” defines users, peers and friends operating over the IAX2 (Inter-Asterisk eXchange) protocol. A user is a sender of information, a peer is a receiver of information and a friend is both a sender and a receiver. A number of configurations can be made in this file, including decisions concerning which codecs should be allowed or disallowed. An entry in “iax.conf” generally consist of the following elements: type deciding if connections are incoming, outgoing or both secret password to limit the usability to trusted parties context where in the dial plan the incoming connection will be sent host mask to limit the addresses of connectors username to be associated with this entry In this project, two Asterisks are used. One exterior Asterisk handles all connections concerning services of Ericsson Research through a SIP connection to the PSTN. There is also one internal Asterisk which is tailored for this specific service. That is, it handles all audio channels of clients connected to the conference service. The Asterisks are connected over IAX2 and incoming connections are passed from the exterior Asterisk to the conferencing Asterisk for initializations and thereafter audio is sent to and from the clients through this connection. Both Asterisks have entries in their respective “iax.conf” files containing information about the other.. 16.

(23) 4.4. AppKonference[28]. Appkonference is the Asterisk plug-in used to bring conference functionality and audio mixing to this project. The plug-in is written in C[29] and sparsely commented. Thankfully, the code is built up in a logical manner with describing names of functions and variables. This greatly helped in the work of finding sections of interest.. 4.4.1. Functionality. The plug-in already had support for most of the functionality needed in the scope of this project. The exception of course is the ability to mix audio based on the location of the user. In order to add this functionality, the representation of a conference user had to be changed in order to include the location of a conference participant. Furthermore the code controlling the audio mixing had to be supplemented to account for this new parameter.. 4.4.2. Commands. In order to control the location of the user, a command for changing location had to be added. Additionally, a command for retrieving a list of users and moderators in a conference was added. This addition was made after the realization that the state of the voice mixer would lack correct information after a crash or restart in the case where conferences are running during this time. This command is therefore used in the voice mixer whenever it starts to check for running conferences and update its internal state. This is done in combination with the native command for retrieving the currently running conferences.. 4.4.3. Events. AppKonference sends several custom events over the manager interface. Since Asterisk-Java by default can’t handle these, support for them was added manually in the voice mixer. Furthermore an event containing the users and moderators in a conference was created to be used with the newly constructed command. These events are then registered under AsteriskJava in the voice mixer at startup.. 17.

(24) Chapter 5. API 5.1. Platform. The API is written for Java Platform, Micro Edition, also known as Java ME. Java ME is a Java version designed for mobile devices which is the main target platform of this API. Using Java Me doesn’t make the API exclusive for mobile devices, but provides a general structure suitable for cross platform development, since web applications and other software programs can be written with a subset of Java ME techniques. In order to provide this generality the API provides both a constructor for MIDlets and one general constructor. The MIDlet constructor automatically handles incoming call requests and answer events. The general constructor lets the developer handle these events and is used when targeting another platform, or for when more control is needed when writing a MIDlet.. 5.2. Networking. In order to open up a connection between the client application and the voice mixer, the SocketConnection class of the Java ME standard library was used. The major advantage when using a SocketConnection over the alternative UDPDatagramConnection is the reliable delivery of information. When using an UDPDatagramConnection it is impossible to guarantee that packets are delivered in the correct order. A SocketConnection keeps a persistent TCP/IP[30] connection between the client and the voice mixer and makes sure that packets are delivered and in the correct order, resending lost packages.. 18.

(25) 5.2.1. Sender. From the SocketConnection an outputStream is created and passed to the Sender class. The Sender is responsible for sending data to the voice mixer. The Sender contains a queue, where actions are placed by the client after which the Sender is notified. The Sender will then proceed to send all actions contained in its queue and then go into a waiting state until more actions are available.. 5.2.2. Receiver. From the same SocketConnection an inputStream is also created and passed to the Receiver class. The Receiver has two responsibilities. Firstly to receive the data sent by the voice mixer and secondly to translate it into events appropriate to pass on to the application. When the received data has been translated into an event, it is then passed to an event queue in the ConferenceClient which is notified that a new event is available.. 5.2.3. KeepAlive. One noticeable problem with having both an inputStream and an outputStream on the same SocketConnection was that the Reader would lock down, queuing it’s input in a buffer before receiving it, waiting for the Sender even if the Sender ’s output queue was empty. This problem was resolved along with another problem, namely the fact that mobile phone service providers cut lingering connections when no data is being sent for a certain time. This timeout value is decided individually by each provider making it harder to resolve in a static way. By letting the client periodically send a heartbeat message to the voice mixer, both problems were resolved at once. This allows the voice mixer to know that the client is still active as well as keeping the connection open in both directions.. 19.

(26) 5.3. platformRequest[31]. Version 2.0 of the Mobile Information Device Profile (MIDP) includes a method that enables MIDlets to invoke external platform services on the mobile phone. These services include the initiation of a voice call as well as downloading and installing MIDlets from a URL. When using this API as a way of extending a MIDlet with conference functionality, a call to platformRequest is used to notify the native part of the mobile phone that a call is to be made. After a request to start or join a conference has been sent to the voice mixer, a reply is sent containing a number to dial. The native part then takes control of the phone from the MIDlet and after prompting the user to confirm the request to dial, the call into the conference is made. When the user has joined the conference, the voice mixer sends a confirmation message to the MIDlet, which then requests control back of the phone. The MIDlet will resume at the Displayable used prior to initiating the call, with the call resuming in the background. This behavior allows the user to control the conference upon entering it. A Displayable is an object which has the capability of being placed on the display of the phone. This behavior is obviously meaningless if the API is used on a different platform and may be undesirable in some MIDlets as well. For this reason the ConferenceClient has an additional constructor leaving more control in the hands of the developer. When using this constructor, the developer is required to handle the CallEvent as well as the AnswerEvent if need be. This provides a greater generality and flexibility for the developer, allowing the API to be used on other platforms than mobile phones.. 5.4. ConferenceClient. This is the most important class of the API. All conference functionality is available to the client through this class. It is also the only class the client can access apart from the event classes. All translation of actions into commands understandable by the voice mixer is done in this class. It also handles all forwarding of events from the Reader to the client application. A list of methods accessible from this class can be found in appendix A.. 20.

(27) 5.5. API restrictions. Some physical limitations in this project include when it comes to the number of conference participants who can use the services simultaneously. This has to do with the processing power of the server where the Asterisk and the voice mixer is located as well as the bandwidth available for incoming calls. In addition to this, some limitations have to be implemented manually to prevent a developer from using up all available bandwidth, hindering other content creators from using the service. Each service constructed using the API has its own <DEVELOPER_KEY> and every such key has a limit on the number of “conference legs” that may be created with it. A “conference leg” is a participant in a conference, indifferent to whether it has joined or created the conference. This limit is there to prevent abusing developers from creating infinitely many conferences on one key. A limit on the maximum number of participants in a conference was also implemented to keep users from creating conferences deemed to large. A way to avoid abuse by users who call with flat rates was also incorporated. Flat rate pricing is when a user has a fixed price to pay, independent of how much is called for. To prevent users from setting up “hotlines” on flat rates and have an “infinitely long” call on one leg per member hogging server bandwidth, a limit on conference duration was added. All these limits are configurable along with several other server properties. A way of preventing users from taking advantage of the service to make free calls also has to be made. The initial business model of the service was a cost per conference or conference member and not for the actual time spent in the conference. This in combination with dial-out would mean that a user could make an infinitely long call for a very small cost. The real cost for the call would have to be paid by Ericsson Labs. By dial-out it is meant that the conference calls the participants phones and place them in the same conference automatically. For this reason dial-out was replaced by dial-in, meaning that the client calls in to the conference and subsequently pays the price of the call.. 21.

(28) 5.6. Obfuscation. The Java programming language is designed for portability. Compiling Java programs into byte code makes them platform independent, but also introduces some problems. The compiled byte code contains much of the information stored in the source code, which makes it relatively simple to reverse engineer. This is obviously not acceptable when writing closed source projects in Java which you want to protect. Obfuscation does in no way make reverse engineering impossible, but is instead a means to make it more time consuming and require more effort. Code obfuscation generates new code which is functionally identical to the original code, but is more difficult to understand. Some examples of ways to obfuscate code include: • Splitting, merging, changing dimensions and reordering elements of arrays. • Reversing loops and replacing for-loops with while-loops or even recursion. • Inlining functions and inserting code that is never executed. • Replacing method and variable names with short meaningless strings. While these methods make the code harder to understand and reverse engineer, it may execute slower or have additional side effects. Shortening method and variable names will make the code size smaller, but unwrapping loops and inlining functions can make it bigger yet. When obfuscating, there is obviously a trade-off between the increased security and application size and execution speed. Obfuscation has been used in this project to make the API smaller and harder to reverse engineer. Code obfuscation has only been performed to a point, to decrease the size of the API, but not affect the performance of applications using this API.. 22.

(29) Chapter 6. Application This chapter gives an example of how to create a simple application for a mobile phone using the group Voice Mixer API. The first step is to create a Java ME MIDlet. This will align the project with a platform suitable for mobile phones. If a software development environment such as Eclipse is used, adding the ConferenceClient API as a referenced library will provide access to all the functionality within it. When the project setup is complete, the MIDlet can be created. In this example, the class is called MyFirstConferenceClient. By extending the MIDlet class, the client will become a Java ME application. Two interfaces are also implemented. Implementing CommandListener provides the means to add Commands to the screen and recognize the choices the user makes in order to perform a function. The ConferenceListener interface provides a means of receiving events from the voice mixer. Examples of how one can use both these interfaces follow later in this chapter. The shell for the client should now look something like this:. public class MyFirstConferenceClient extends MIDlet implements CommandListener, ConferenceListener{ protected void destroyApp(boolean arg){} protected void pauseApp(){} protected void startApp(){} public void commandAction(Command com, Displayable dis){} public void receiveEvents(ClientEvent evt){} }. 23.

(30) The next step is now to initialize the client with a graphical user interface. To facilitate that this is done when the client starts, we create a constructor and place the code inside it. For this example a Form is used to contain all items placed on the screen. A StringItem is used to represent text on the screen to the user. The StringItem is appended to the Form which is set as the current display, making it appear on the screen when the application starts. Adding the listeners result in a constructor as follows:. private ConferenceClient conf; private StringItem si; private Form f; public MyFirstConferenceClient(){ conf = new ConferenceClient(this, <DEVELOPER_KEY>); Form f = new Form("myApp"); si = new StringItem("Status:","\n"); f.append(si); f.setCommandListener(this); Display.getDisplay(this).setCurrent(f); conf.setListener(this); } Note that the ConferenceClient constructor takes two arguments. The first argument is the MIDlet it will belong to and the second argument <DEVELOPER_KEY>, is the key provided by Ericsson Labs to identify this application as valid to use the services requested by it. Emulating the application with the WTK on a SonyEricsson K750 provides a graphical example of how it could look on a mobile phone. As can be easily seen, this application does not yet do anything and provides no means for the user to control the behavior of the application. To facilitate this, a few Commands are created as private variables of the application.. 24 Figure 6.1: Application.

(31) private private private private private. Command Command Command Command Command. exitCommand = new Command("Exit", Command.EXIT, 1); startCommand = new Command("Start", Command.ITEM, 1); createCommand = new Command("Create", Command.ITEM, 1); leaveCommand = new Command("Leave", Command.ITEM, 2); locCommand = new Command("Location", Command.ITEM, 3);. When the Commands have been created they can be added to the Form. The type and index number of the Commands decide in which order they will be added to the phone menu. For this application, we’ll place them in the constructor.. public MyFirstConferenceClient(){ ... f.addCommand(startCommand); f.addCommand(exitCommand); f.addCommand(createCommand); f.addCommand(leaveCommand); f.addCommand(locCommand); ... } Now that the constructor is finished, starting the emulator again shows what the application will look like when finished. The application now contains a start command under the left option item on the phone and a push-up menu under the right option menu with the rest of the commands specified. The user can now choose between different actions, but nothing will happen if they are pressed, not until behavior for these actions are specified. This is where the CommandListener comes in. When the user presses on of the items specifying a Command, the method public void commandAction(Command com, Displayable dis) will be called. Lets add some simple actions the application can take for each menu item.. Figure 6.2: Client with menus 25.

(32) Some simple but logical actions are chosen to be represented by the menu items in this example. Pressing Start will cause the client to connect and login to the voice mixer using the supplied phone number to identify this particular client. The method openConnection(String <PSTN_IDENTIFIER>) both opens the connection and thereafter logs onto the voice mixer. Pushing the Create button will surprisingly enough tell the client to create a new conference. Creating a new conference is accomplished by calling createConference(String <CONFERENCE_NAME>), where <CONFERENCE_NAME> is a String representing the name intended for the conference. If a conference with the specified name already exists, an ErrorEvent of the type CONFERENCE_EXIST_ERROR will be sent by the voice mixer. An example of one way to handle this event will be shown later in this chapter. Continuing in the same logical manner, the Leave button will cause the client to leave the current conference, should it be in one. A simple call to leaveConference() accomplishes this behavior. The Location command is set to statically assign the location of the user to the fictional value <LOCATION>. This is done with a call to setLocation(<LOCATION>). Note that in a real application, the user would decide his/her location dynamically to get the most out of the feature. To keep this example simple, a static location is used. Finally, the exit command is set to signal the MIDlet that the application has finished executing and that it’s time to end it. This can be done with a call to the inherited notifyDestroyed() method. Now that every menu option has an action associated to it, it’s time to look at the event handling. If the method listenForEvents(boolean listen) is set to true, the voice mixer will send events to the client to let it know what is going on in and around the conference. Receiving events is enabled by default. To disable the voice mixer sending events listenForEvents(false) can be called. For obvious reasons the application need to be sure that it has a connection open and has finished logging in to the voice mixer before attempting this. There are a number of special events that are sent regardless of what is specified.. 26.

(33) Most of these special events are important for the functionality of the client, such as knowing when to call a newly created conference. Other events, such as the ActionResponseEvent is sent to let the application know that some special actions have been completed, such as the openConnection(String <PSTN_IDENTIFIER>) and the listenForEvents(boolean listen) action. The ActionResponseEvent received after openConnection() is completed is of the type LOGIN. A good idea is therefore to wait for this event before sending any actions to the voice mixer, since there is no guarantee that the events are truly sent unless the client is connected to the voice mixer. The reason behind this behavior is the fact that the CommandListener and the networking functionality can’t be in the same thread. This comes from the fact that the implementation of Java ME locks down the thread when this occurs. The networking functionality is therefore running in a separate thread in the ConferenceClient class. Since the Java Virtual Machine (JVM) decides at runtime which thread should run at a given time, a notification is needed to know when certain actions are completed, so that other threads can wait with performing actions until they become meaningful. The following code would therefore be a safe way of setting the client to stop listening for events. It ensures that the client has logged in on the voice mixer before telling it to stop sending events. if(evt instanceof ActionResponseEvent){ if(((ActionResponseEvent)evt).type() == ActionResponseEvent.LOGIN){ conf.listenForEvents(false); } }. The ConferenceLeaveEvent is another event that may be interesting to listen for. This event signals that someone has left the conference. If it is the current client that has left, either of its own accord or kicked by a moderator, it can be meaningful to cut the connection to the voice mixer, unless the client intends to rejoin or create a new conference. An example of what can be done with this event is thus to close the connection to the voice mixer when the client has left the conference.. 27.

(34) This behavior translated into code could look something like this: if(evt instanceof ConferenceLeaveEvent){ if(((ConferenceLeaveEvent)evt).getUser().equals(<MOBILE_NUMBER>)){ conf.closeConnection(); } }. When creating a conference with a name that is already occupied by an existing conference, an ErrorEvent of the type CONFERENCE_EXIST_ERROR is sent by the voice mixer. For this test application, it is assumed that if the conference name is occupied, the client wants to join it. In a real application it might make more sense to prompt the user for a new name, but this behavior is enough for testing purposes and is reached with the following bit of code. if(evt instanceof ErrorEvent){ if(((ErrorEvent)evt).getType() == ErrorEvent.CONFERENCE_EXIST_ERROR){ conf.joinConference(<CONFERENCE_NAME>); } }. For purposes of testing this application, some graphical feedback would be desirable. Printing some of the events to the display will be enough to accomplish this. To simplify the code a small internal method is constructed appending a given text-string to the StringItem controlling the output on the display. private void addToScreen(String text){ si.setText(si.getText()+text+"\n"); }. The full code of this example application can be found in Appendix B. To test the code, replace <MOBILE_NUMBER>, <CONFERENCE_NAME> and <LOCATION> with desired values, build the project and install it on a mobile phone. This final version of the code can’t be constructively executed in an emulator since createConference(String <CONFERENCE_NAME>) requires access to native platform functions of the mobile when used in a MIDlet.. 28.

(35) Chapter 7. Conclusions 7.1. Evaluation. Testing has been divided into several phases progressing continually during the course of the project as new methods became available and required.. 7.1.1. Phase 1. The first stage of testing involved setting up the Asterisk and getting it to behave correctly. Once the Asterisk was configured, two softphones (one X-Lite[32] and one SJphone[33]) were used to perform test calls, making sure that calls are handled correctly internally by the Asterisk. A softphone is a software program used to make calls over the Internet. The softphones were registered on the Asterisk over a SIP channel and calls were made between them. Actual audio functionality were never tested in this stage, due to the fact that the same computer hosted both softphones and also lacked a microphone.. 7.1.2. Phase 2. The same softphones were also used for testing in the second stage. This stage involved both the Asterisk and the voice mixer. The main focus laid on testing the voice mixer. Letting it create and manage conferences and calls between the softphones.. 29.

(36) 7.1.3. Phase 3. The third phase was divided into two parts. In the first part the networking functionality was tested and made operable in conjunction with the voice mixer. A small test client was made in Java based on the API and used to send commands to the voice mixer and receive events from it. At this point the API was written in Java. Once the networking functionality was satisfactory, the API was converted to Java ME. Java ME is based on the functionality of Java 1.3 so several common methods were suddenly missing. Part of the API code, especially concerning the network connection had to be rewritten. Once this was completed, a Java MIDlet was created in order to test communication between the voice mixer and a mobile phone. The MIDlet was emulated mainly on a SonyEricsson JP7 240x320 Emu using the Sony Ericsson SDK 2.5.0.3 plug-in for Eclipse. It was also tested on a number of other platforms, but the only difference was how the shell of the emulated phone appeared.. 7.1.4. Phase 4. The final phase of testing was the most important phase, since it tested how a client implemented using the API installed on a real mobile phone behaves. This was naturally the most extensive phase of testing and several different mobile phones were used, including the Sony Ericsson K800i and the Sony Ericsson K810i. Although any mobile phone supporting Java ME could have been used, Sony Ericsson phones were handily available since the project was done at Ericsson Research. This was also the phase when the conferencing functionality and especially the location based voice mixing finally could be tested. Some conferences had been created and tested in previous phases, but not with sound. The mobile phone implementation finally made this possible. Location based voice mixing was tested by placing several mobile phones in the same conference and letting some of them set the same location. When it was concluded that the ones specifying the same location could not hear each other, the test was deemed a success.. 30.

(37) When the functionality of the API had been confirmed, a test implementation was made on top of the EricssonGeoChat application. A project made by another master thesis student at Ericsson research (Xin Jin). This application allows people to create chat rooms on a map, enter them and chat with all other people in the same room. Entering a chat room can be done either by physically entering the area of the map corresponding to the room or by virtually entering a room anywhere in the world. To be able to physically enter a room, the mobile phone used is required to be equipped with a GPS. This application was supplemented with an option to enter a voice chat with the other participants of the chat room, while still being able to continue chatting with everyone in the room. Another test made at this point was a sort of stress test for the Asterisk. Unfortunately not more than 9 mobile phones were available for this test, so it is unknown how many conference participants can use the voice mixer simultaneously. These 9 phones were tested all in one conference and also divided up over 3 different conferences without problem. Since the physical limitation on the Asterisk could not be tested, theoretical limits were calculated. The theoretical number of simultaneous calls possible is dependent on the codecs used and the bandwidth available. An Asterisk with a 10Mbit Ethernet line for itself could support a maximum of 261[34] simultaneous calls encoded with Global System for Mobile communications (GSM). This number is calculated using a worst case scenario with the most demanding GSM codec available on the Asterisk with an additional overhead of 5% as well as assuming no optimizations have been made in the form of trunking. Under the same conditions but using another common codec G.711 (u-law/a-law), 109 simultaneous calls could be achieved. Note that these are theoretical limits calculated by using a bandwidth calculator for VoIP[34] and the real limitations might differ from these.. 31.

(38) 7.2. Discussion. During the course of this project, a high level conferencing API has been constructed. This API provides easy to use commands for performing common operations associated with a conferencing application. These commands include, but are not limited to creating, leaving and joining conferences, as well as muting and kicking users. The user also has the ability to selectively mix the audio of the other members of the conference. This feature can be used to not receive audio from conference participants that are so close that they can be heard without the use of a conference. The API is optimized and tested for use on mobile phones, but has been written general enough to usable on any platform supporting Java ME using Mobile Information Device Platform 2.0 (MIDP 2.0) and Connected Device Limited Configuration (CLDC). A voice mixer lies on the server side controlling most of the functionality of the API. The API sends commands to the voice mixer which performs them and makes necessary changes in states. When actions are completed or events are received from the Asterisk, the voice mixer sends events to notify the clients. An Asterisk is used on the server side to handle incoming connections according to rules set up by the voice mixer. The Asterisk contains a conference plug-in called AppKonference, which has been modified to provide the location based voice mixing. It was originally intended that an application called Ericsson Geo Chat, constructed as another Master Thesis, was going to be used in the testing of this API. Unfortunately this application proved to have server issues as well as being slow and unpractical to use. Because of this, a new test application had to be constructed from scratch. During the course of the project, several alternative solutions have been developed, but deemed unsatisfactory. The most prominent of them have been mentioned briefly in this report, but all in all, it’s the final solution that has been presented.. 32.

(39) 7.3. Future improvements. • The number of concurrent users of the conferencing service is limited by the processing power of the server and the bandwidth available. To increase the number of clients able to concurrently use the service trunking could be implemented between the Asterisks. Trunking allows for the data of multiple calls to be merged into one single stream of packets. This reduces the IP overhead without creating additional latency. Since the data sent per connection is reduced, more connections can run simultaneously for the same bandwidth cost. Trunking can be enabled over the IAX connection by adding hardware timers to the Asterisks. • Finish support for speech detection. Speech detection is implemented in the voice mixer and in the client API. The conference plug-in is according to documentation capable of delivering information on who starts talking and when. The problem is that the conference plug-in is not configured correctly to provide this functionality. Tests this far have had mixed results and not been good enough to include in this draft of the API. • An option to password conferences. At the moment anyone can join a conference by name or by name of a participant. A way of placing passwords on conferences is needed to ensure privacy. • Prevent users muted by moderators to unmute themselves. If a moderator mutes a single user or a whole conference, any user can still unmute itself. A desirable feature would be to keep track of mutes done by moderators and only allow moderators to unmute in such cases. • Encrypt all traffic sent between clients and the voice mixer. Encryption of data can prevent third parties from intercepting information sent by the clients. This information could potentially be used to emulate other clients, using their identity to query the voice mixer or sending false events to the clients.. 33.

(40) Bibliography. [1] B USINESS K NOWLEDGE S OURCE: http://www.businessknowledgesource.com/technology/teleconferencing_featured_article_026641 , (2009-11-30) 1.1 [2] C ISCO T ELEPRESENCE: http://www.cisco.com/en/US/netsol/ns669/networking_solutions_solution_segment_home.html , (2009-11-30) 1.3 [3] AT&T T ELEPRESENCE: http://www.business.att.com/enterprise/Service/unifiedcommunications-enterprise/conferencing-servicesenterprise/telepresence-enterprise/campaign=telepresence/ , (2009-11-30) 1.3 [4] V ESTA N ETWORKS: http://www.vestanetworks.com/canadian_conferencing_services.php , (2009-11-30) 1.3 [5] A LLCONFERENCECALLS: http://www.allconferencecalls.se/phone-conference/voice/ , (2009-11-30) 1.3 [6] J AVA: http://en.wikipedia.org/wiki/Java_(programming_language) , (2009-11-14) (document), 2.1 [7] O BJECT- ORIENTED PROGRAMMING: http://en.wikipedia.org/wiki/Object-oriented_programming , (2009-11-14) (document), 2.1 [8] J AVA ME: http://java.sun.com/javame/technology/index.jsp , (2009-11-25) (document), 2.2 34.

(41) [9] MIDP 2.0 (JSR 118): http://java.sun.com/products/midp/ , (2009-11-25) (document), 2.2 [10] CLDC 1.1 (JSR 139): http://java.sun.com/products/cldc/ , (2009-11-25) (document), 2.2 [11] P RIVATE B RANCH E XCHANGE , W IKIPEDIA: http://en.wikipedia.org/wiki/Private_branch_exchange , (2009-11-18) (document), 2.3 [12] A STERISK , W IKIPEDIA: http://en.wikipedia.org/wiki/Asterisk_(PBX) , (2009-07-27) 2.3 [13] A STERISK -J AVA , VO IP- INFO: http://www.voip-info.org/wiki/view/Asterisk-java , (2009-11-18) (document), 2.4 [14] M EET M E , VO IP- INFO: http://www.voip-info.org/wiki/view/Asterisk+cmd+MeetMe , (2009-11-18) 2.5 [15] VO IP, I NTERNATIONAL E NGINEERING C ONSORTIUM: http://www.iec.org/online/tutorials/int_tele/index.asp , (2009-07-27) (document), 2.6 [16] VO IP, W IKIPEDIA: http://en.wikipedia.org/wiki/Voice_over_Internet_Protocol , (2009-07-27) (document), 2.6 [17] SIP, IETF: http://www.ietf.org/rfc/rfc3261.txt , (2009-07-27) (document), 2.6.1 [18] RTP, IETF: http://www.ietf.org/rfc/rfc3550.txt , (2009-07-27) (document), 2.6.2 [19] H.323, IEC: http://www.iec.org/online/tutorials/h323/topic01.asp , (2009-12-07) 2.6.2 35.

(42) [20] IAX, RFC E DITOR: http://www.rfc-editor.org/authors/rfc5456.txt , (2009-11-10) (document), 2.6.3 [21] E RICSSON L ABS: https://labs.ericsson.com/ , (2009-12-08) 2.7 [22] E CLIPSE: http://www.eclipse.org/ , (2009-11-23) 3.1 [23] S ONY E RICSSON SDK 2.5.0.3: http://developer.sonyericsson.com/site/global/docstools/java/p_java.jsp , (2009-11-23) 3.1 [24] V IM: http://www.vim.org/about.php , (2009-11-23) 3.1 [25] UNIX: http://www.unix.org/what_is_unix.html , (2009-11-23) 3.1 [26] E XTENSIONS CONFIGURATION , A STERISKGURU: http://www.asteriskguru.com/tutorials/extensions_conf.html , (2009-07-27) (document), 4.3.1 [27] IAX CONFIGURATION , VO IP- INFO: http://www.voip-info.org/wiki/view/Asterisk+config+iax.conf , (2009-11-18) (document), 4.3.2 [28] A PP KONFERENCE: http://appkonference.sourceforge.net/ , (2009-11-12) (document), 4.4 [29] C, W IKIPEDIA: http://en.wikipedia.org/wiki/C_(programming_language) , (2009-11-23) 4.4 [30] TCP, FAQS: http://www.faqs.org/rfcs/rfc793.html , (2009-12-07) 5.2 36.

(43) [31] PLATFORM R EQUEST, IETF: http://www.ietf.org/rfc/rfc2806.txt , (2009-11-18) (document), 5.3 [32] X-L ITE , C OUNTER PATH: http://www.counterpath.net/x-lite.html , (2009-11-19) 7.1.1 [33] SJ PHONE , SJ L ABS: http://www.sjlabs.com/products.html , (2009-11-19) 7.1.1 [34] VO IP BANDWIDTH CALCULATOR , A STERISK GUIDE: http://blog.asteriskguide.com/bandcalc/bandcalc.php , (2009-11-20) 7.1.4. 37.

(44) Appendix A. Important methods This section contains a list of the most important methods in the Group Voice Mixer API and a very basic description of what they do.. A.1. Connection. openConnection(String username) Opens a connection to the voice mixer and logs in using the supplied username. The username is the clients identity on the PSTN typically a phone number or a SIP name. closeConnection() Closes the connection to the voice mixer. listenForEvents(boolean listen) Decides if the voice mixer should send events to the client, such as users joining or leaving, or only the most vital events providing basic functionality to a MIDlet implementation. True by default. setListener(ConferenceListener listener) Sets the listener which should receive the events sent by the voice mixer if listenToEvents is set to true. removeListener() Removes the current ConferenceListener.. 38.

(45) A.2. General commands. createConference(String conferenceName) Creates a conference called conferenceName unless such a conference already exists. If the conference already exists, an error is sent back to the client signaling this. joinConference(String conferenceName) Joins the conference conferenceName if it exists. joinConferenceOfUser(String user) Tries to join the conference containing user, where user is the identity used by that client to login to the voice mixer server, most commonly a phone number. leaveConference() Leaves the current conference. muteMe(boolean mute) Set to true to mute oneself and false to unmute. setLocation(String location) Sets the location of the client. Used to decide how the audio should be mixed for this client. Audio sent by clients specifying the same location will not be mixed. getConferenceStatus() Requests the voice mixer to send a list of participants and moderators of the current conference. Reply is received as an event.. 39.

(46) A.3. Moderator commands. endConference() Hangs up the connection to everyone in the conference and ends it. muteConference(boolean mute) If mute is true, everyone in the conference is muted and if false, unmuted. muteUser(String user, boolean mute) Mutes the specified user. Can be used to mute oneself independent of being a moderator. kickUser(String user) Kicks the specified user from the conference.. 40.

(47) Appendix B. Example Application import import import import import import import. javax.microedition.lcdui.Command; javax.microedition.lcdui.CommandListener; javax.microedition.lcdui.Display; javax.microedition.lcdui.Displayable; javax.microedition.lcdui.Form; javax.microedition.lcdui.StringItem; javax.microedition.midlet.MIDlet;. import import import import import import import import. conference.ConferenceClient; conference.ConferenceListener; events.ActionResponseEvent; events.AnswerEvent; events.ClientEvent; events.ConferenceJoinEvent; events.ConferenceLeaveEvent; events.ErrorEvent;. public class MyFirstConferenceClient extends MIDlet implements CommandListener, ConferenceListener{ private ConferenceClient conf; private StringItem si; private private private private private. Command Command Command Command Command. exitCommand = new Command("Exit", Command.EXIT, 1); startCommand = new Command("Start", Command.ITEM, 1); createCommand = new Command("Create", Command.ITEM, 1); leaveCommand = new Command("Leave", Command.ITEM, 2); locCommand = new Command("Location", Command.ITEM, 3); .... 41.

(48) ... public MyFirstConferenceClient(){ conf = new ConferenceClient(this, <DEVELOPER\_KEY>); Form f = new Form("myApp"); si = new StringItem("Status:","\n"); f.append(si); f.addCommand(startCommand); f.addCommand(exitCommand); f.addCommand(createCommand); f.addCommand(leaveCommand); f.addCommand(locCommand); f.setCommandListener(this); Display.getDisplay(this).setCurrent(f); conf.setListener(this); } protected void destroyApp(boolean arg) {} protected void pauseApp() {} protected void startApp() {} public void commandAction(Command com, Displayable dis) { if(com == startCommand){ conf.openConnection(<MOBILE_NUMBER>); }else if(com == exitCommand){ notifyDestroyed(); }else if(com == createCommand){ conf.createConference(<CONFERENCE_NAME>); }else if(com == leaveCommand){ conf.leaveConference(); }else if(com == locCommand){ conf.setLocation(<LOCATION>); } } private void addToScreen(String text){ si.setText(si.getText()+text+"\n"); } .... 42.

(49) }. ... public void receiveEvents(ClientEvent evt) { if(evt instanceof ActionResponseEvent){ if(((ActionResponseEvent)evt).type() == ActionResponseEvent.LOGIN){ addToScreen("logged in"); } }else if(evt instanceof ConferenceLeaveEvent){ if(((ConferenceLeaveEvent)evt).getUser().equals(<MOBILE_NUMBER>)){ addToScreen("left conference"); conf.closeConnection(); addToScreen("logged out"); }else{ addToScreen(((ConferenceLeaveEvent)evt).getUser()+" left"); } }else if(evt instanceof ConferenceJoinEvent){ addToScreen(((ConferenceJoinEvent)evt).getUser()+" joined"); }else if(evt instanceof AnswerEvent){ addToScreen("entered conference"); }else if(evt instanceof ErrorEvent){ if(((ErrorEvent)evt).getType() == ErrorEvent.CONFERENCE_EXIST_ERROR){ conf.joinConference(<CONFERENCE_NAME>); } } }. 43.

(50)

No results found