Building complex Voice over IP (VoIP) applications based on open-source

Sebastian Schumann, Ondrej Lbaj, Pavol Podhradsk

Slovak University of Technology (STU), Ilkoviova 3, 812 19 Bratislava, Slovak Republic E-mail: {schumann;labaj;podhrad}@ktl.elf.stuba.sk

Abstract - The paper summarizes and proofs that existing VoIP programs are powerful and flexible enough to build complex applications. The applications are independent and can be used either stand-alone or within carrier-grade Telco environments. The described example of building a call center application (outbound calling) shows the power that lies not only in existing open-source Session Initiation Protocol (SIP) servers, but also in simple SIP tools. The costs for implementing those systems are at a very low level, as the functions each project performs are rather kept simple, but the combination possibilities are tremendously flexibility. The presented application has been deployed successfully within NGNlab [1] as a Proof of Concept (PoC). Keywords - SIP, Tools, Open-source, Proof of Concept, Call generation, NGNlab, ELMAR, Croatia

1. INTRODUCTION In the area of VoIP, the variety of useful opensource applications reached huge dimensions during the last years. Besides the more than eight years old SIP application server SIP Express Router (SER) or one of the commonly used Public Branch Exchange (PBX) server Asterisk [2], many new forks and also tools grew around those programs. The successful and feature-rich fork of SER, OpenSER, started in 2005 and forked again in 2008 to Kamailio and OpenSIPS [3]. Different approaches and also configuration parameters make FreeSWITCH and Yate successful forks of Asterisk. One can see: The open-source SIP server and PBX range1 is very wide and complex. However, features were only extended within the project and not too much to complex combined applications yet. Having many different open-source server solutions lead also to the development of SIP based clients (e.g. Twinkle, Ekiga, Kphone) or tools for testing (e.g. SIPSAK) and penetrating (e.g. SIPp [4]) the server applications. This paper will not deal with the development of yet another application or tool, but rather use existing software and creative approaches to build complex exemplary VoIP applications. The author will show in this paper that opensource tools are very flexible and can be combined to fulfill even the functions, where only expensive products are available yet. The author will demonstrate that the currently available applications are flexible enough to be even combined with closed-source applications. It will be shown that even the deployment of small but complex open-

source islands within big vendor Telco infrastructures will pay off for simple applications. 2. APPLICATION TASK The target application should perform one of the tasks a call center application has to fulfill nowadays: Call a list of users. Open-source PBX software like Asterisk can do that already2, but as mentioned before, the application will not just be a PBX add-on but is aimed to be rather independent. Companies that have own inbound call-center and just want to generate calls should be able to use the target application. Companies that have IP based systems, which are much more powerful, are also targeted to benefit from an independent calling application. The target application itself will generate the calls and provide detailed statistics about the calls in the end. The application should be independent from the media system behind it (interoperability, independence). This simple task of just calling is more complex regarded closely: List of users usually available in text format (parsing) Establishment of many calls in parallel Codec independence (called user and media server codec preferably not pre-set)

The final application must establish calls to a list of users and connect to some media resource server (e.g. to play a pre-defined announcement (audio file) or Interactive Voice Response (IVR) system) after the user accepted the incoming call. In
2

The mentioned SIP proxy and PBX applications should demonstrate the variety of applications with similar functions. They should be considered as exemplary and not complete list.

Several possibilities for call establishment directly from Asterisk are e.g. .call files or the manager Application Programming Interface (API) [5]

the end of the announcement, the system must release the call. All calls should be logged, including their state. The log should be ready for further evaluation and processing within the application (e.g. recalling of unreachable users). 3. SYSTEM DEFINITION The tools for the above defined tasks are available within the open-source application scope. Also the SIP signaling theory allows the set-up of such a complex system. This section will define the system and all necessary tools to build the previously defined exemplary application. The input for the system will be a simple text file with telephone numbers of the users that should be called. This can be easily exported from existing sources (e.g. Customer Relationship Management (CRM) systems, databases, registers). As all calls are regarded within the SIP signaling scope, predefined domains per number should be possible (system should be able to send outgoing calls to different operators via different gateways). The target user is thus defined by a unique SIP Uniform Resource Identifier (URI). Another input parameter should be the destination the system should finally connect the called user with. This destination will be also described by a SIP-URI and can either be a PBX like Asterisk (for simple IVR or media announcements towards the user) or some other system that will process the established call further. The system (see also Fig. 1) will consist of Call generator (SIPp) Call evaluation system (OpenSIPS) Media system (Asterisk)
timer cron .csv user data

The system will receive the input described within section 3. The call will be established through OpenSIPS (see section 3.2). If the establishment was successful, the second leg towards the media system for play back and further interaction3 will be established. SIPp has the possibility to "negotiate" also the codecs between the systems. The trace in Fig. 2 shows that the Session Description Protocol (SDP) offer towards the media system is the SDP answer from the user side.
User OpenSIPS SIPp PBX | INVITE |(1) INVITE | | |<------------#<------------| | off-hook |(2) 200 SDP1 | 200 SDP1 | | |------------>|------------>| | | | |(3) INV SDP1 | | | |------------>| | | |(4) 200 SDP2 | | | |<------------| | | |(5) ACK | | | |------------>| | ACK SDP2 |(6) ACK SDP2 | | |<------------#<------------| | |(7) RTP | | | |.........................................| End: Either user hangs |(8) BYE | BYE | | |------------>#------------>| | | | | BYE | | | |------------>| or system stops | | |(8) BYE | | | |<------------| | BYE | BYE | | |<------------#<------------| | # Accounting on OpenSIPS for statistics

Fig. 2. Call flow for session establishment acc. [4]4 The session chain can be as follows: Cron initiates the call controller to establish the calls OpenSIPS creates Call Data Records (CDRs) of all calls in its local database. It monitors also the SIP timers After each call interval, a comparison between successful calls from the CDRs and the CSV will erase the numbers where calls have been successfully established The remaining users can be called at some later state again.

Analyzer media

Generator

Media

Fig. 1. General components The call generator will be controlled by a timer (e.g. cron provided by the underlying operating system) and data input through a Comma Separated Value (CSV) file. 3.1 SIPp SIPp will be used as call controller (Third Party Call Control (3PCC) [6]). The program will establish the call between both "parties".
4

Media announcement and further media interaction happens directly between the media system and the user. The media stream will be directed between both applications in that case. 1xx provisional responses and the corresponding 200 OK message for the BYE transaction have been omitted. The figure shows mainly accounting points and the SDP negotiation.

The OpenSIPS CDRs can be compiled to a meaningful chart which users picked up, how long the average listened and how many attempts it took in average to reach a user.

3.2 OpenSIPS The SIP application server OpenSIPS is a simple proxy in the communication path between call generator and user (compare Fig. 2). The configuration of the proxy includes accounting information (acc module, for CDR generation) and call statistics (statistics module) for runtime evaluation. The previously mentioned different call routing (see section 3) for optimized outgoing call routing can be done either in SIPp (CSV input) or using OpenSIPS (evaluating user name or domain parameter from the SIP request URI). 3.3 Asterisk The media server is only required, if no existing IVR/media source or another system will be used for handling the established calls. For the PoC (see also section 4), Asterisk has been used as media server playing pre-defined announcements. Two announcements have been set and SIPp chose for each user the pre-set announcement (one parameter in the CSV file). 3.4 Action flow Fig. 3 shows the logical flow of the actions within the system.
Call user No Call established Yes Connect to media system Media Interruption Call released on user side End condition on media system*

When the call has been established successfully, the media system will be connected5. Otherwise, the event will be logged. After the media system finishes the call (certain timer for announcements, call release from system), the call will be released towards the user. If the user hangs up first, the call will be released towards the system. Both events will be logged, the user release with the additional parameter time of call (to know e.g. how long a user has been listening to an announcement). The logged values must be available in a suitable form for a later evaluation. 4. PROOF OF CONCEPT The PoC was performed with the following parameters: CSV file with 10 users that should be called Users got pre-defined target domains assigned for both, SIPp interpretation and based on OpenSIPS user name filter Asterisk PBX set-up with announcements in different codecs6

4.1 System The components have been installed on three machines: The call generator, cron and OpenSIPS were running on one system. To simulate the possibility of real different environments, users have been simulated on another machine with SIPp7. The PBX system has been simulated by a third system having Asterisk installed. All three machines were using the CentOS as operating system. The media system has been defined to handle 10 parallel calls. An announcement with the duration of 10s has been selected. 4.2 Settings The SIPp call generator uses mainly the 3PCC pre-defined call scenarios [7]. The following changes have been performed: The SIP message parameters are not passed via the command, but through the CSV file (-inf users.csv) The SIPp controller instance towards the user listens on port 5070. The instance

LOG

LOG

Release call

* Timer ends, SIPp receives BYE...

LOG
7

Fig. 3. Logical actions of the system

Announcement will be played, the user can interact with an IVR The call controller will receive a certain SDP offer from the user. To be sure Asterisk can reply to that offer with a supported codec, more than one announcement should be available. Also tested with real accounts registered on a SIP proxy.

towards the media system listens on port 5080 (-p 50x0) The call rate has been set to 1 call per second (meeting section 4.1 definitions, -r 1 -rp 1s)

The OpenSIPS proxy server will receive the messages sent from SIPp on port 5060. It passes the message further on to the listening SIPp instance simulating user accounts. OpenSIPS will Record-Route all calls to be able to process in-dialog SIP messages as well. The acc module was used to account the INVITE and BYE messages. The statistics module set the following variables within the script: PROCESSED_INVITE PROCESSED_BYE

In places, where normally a new PBX system set-up with the required application functions would be required, existing infrastructure can be used preferably. The tools for new signaling means are flexible enough to be fully integrated. The next steps and next complex applications to be tested in PoC scenarios will stay in the same area. OpenSIPS is able to handle calls, but no media. A simple PoC for call center applications requires also queuing of inbound calls. An extension for OpenSIPS for such a module could be a good way to show that applications for simple and also more complex signaling are available and efforts for their extension are not too high. ACKNOWLEDGEMENT The first author is also affiliated member of the Institut fr Telekommunikationsinformatik at the Hochschule fr Telekommunikation (HfT) in Leipzig, Germany. STU and HfT are working together on common topics in the area of Next Generation Networks (NGN) since 2006. This paper also presents some of the results and acquired experience from various research projects such as NGNlab project [1], European CelticEURECA project Netlab [8], Leonardo da Vinci projects InCert [9] and Train2Cert [10], AV project: Converged technologies for next generation networks (NGN) No. AV/4/0019/07, Slovak National basic research projects VEGA No. 1/0720/09 and VEGA 1/4084/07. REFERENCES [1] NGNlab - NGN laboratory at Slovak Technical University in Bratislava, http://www.ngnlab.eu [2] Asterisk, http://www.asterisk.org/ [3] OpenSIPS, http://www.opensips.org [4] SIPp, http://sipp.sourceforge.net [5] VoIP-Info: Asterisk auto-dial out, http://www.voip-info.org/tikiindex.php?page=Asterisk+auto-dial+out [6] J. Rosenberg et. al., "Best Current Practices for 3PCC in the SIP", RFC 3725, April 2004 [7] SIPp 3PCC, http://sipp.sourceforge.net/doc3.0/reference.ht ml#3PCC [8] NetLab - Use Cases for Interconnected Testbeds and Living Labs, http://www.celticinitiative.org/Projects/NETLAB/ [9] InCert Next Generation Network Protocols Professionals certification in InCert, International Certificates of Excellence in Selected Areas of ICT, http://incert.eu [10] Train2Cert, Vocational Training for Certification in ICT, http://train2cert.eu

Statistical variables exported by the OpenSIPS core and modules can be accessed in addition. The accounting records can be compiled directly into a new table, where statistical data is calculated from within MySQL. A new procedure could do that regularly. This has not been implemented for the PoC. The Asterisk system has been set up with two extensions, simple Playback() of pre-defined audio data has been assigned. 4.3 Evaluation The PoC has been started and the results were successful so far. The establishment and media transfer has been proven (tracing between machines). Different cases of user behavior have been evaluated. The logging is under modification and improved continuously. If a user does not pick up, OpenSIPS terminates the call towards OpenSIPS (SIP timer monitoring). The accounting records will be merged with the used CSV file and a new CSV file for next calling sessions will be created automatically (call again remaining users, who did not take the call). This is planned to be done automatically using a cron job. The PoC shows that all required function for fulfilling the system task (sec. 2) can be handled with the described set of applications and that there are still possibilities open to improve and extend the system. This will be part of future work. 5. FUTURE PERSPECTIVE The results of the theoretical analysis and the established and tested PoC were successful. It has been proven that nowadays open-source applications reached a certain limit of complexity and are powerful enough to perform complex tasks.