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

Building complex Voice over IP (VoIP) applications based on open-source Sebastian Schumann, Ondrej Lábaj, Pavol Podhradský Slovak University of Technology (STU), Ilkovičova 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-

1

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.

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

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 • • •

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 | | || | | | |(3) INV SDP1 | | | |------------>| | | |(4) 200 SDP2 | | | || | ACK SDP2 |(6) ACK SDP2 | | || | | | | BYE | | | |------------>| or system stops | | |(8) BYE | | | |