IJRIT International Journal of Research in Information Technology, Volume 1, Issue 6, June 10, 2013, Pg. 37-45

International Journal of Research in Information Technology (IJRIT)

www.ijrit.com

ISSN 2001-5569

Design of Scalable & Simple SIP Application Development & Execution Platform 1

1

2

Yashaswini Y K, 2 H K Krishnappa

M.Tech, computer Science, RV College of engineering.

Assistant Professor, Dept. of CSE, RV College of engineering.

Abstract The steady improvements in the networking infrastructure and ever increasing broadband penetration has fueled the resurgence of voice-over-IP (VoIP). One of the important contributors to this growth has also been the development and wide acceptance of the session initiation protocol (SIP). As the market becomes competitive, it is necessary for the service provider to provide innovative applications to users in a shorter time & also provide easy scalability for these applications as the user base increases. Application development platforms have been developed to cater to these needs, but the current platforms suffer from 2 main problems. The application solution is very complex to design and also the platform on which these applications run are not easily scalable. In this work, we address these two challenges and design a simple to use & highly scalable platform.

1. Introduction The Session Initiation Protocol (SIP) is a general-purpose signaling protocol used to control various types of media sessions. SIP is a protocol of growing importance, with uses in Voice over IP, Instant Messaging, IPTV, Voice Conferencing, and Video Conferencing. Wireless providers are standardizing on SIP as the basis for the IP Multimedia System (IMS) standard for the Third Generation Partnership Project (3GPP). Third-party VoIP providers use SIP (e.g., Vonage, Gizmo), as do digital voice offerings from existing legacy Telcos (e.g., AT&T, Verizon) as well as their cable competitors (e.g., Comcast, Time-Warner). SIP Application server are used by most telecom operators to provide SIP based services like IM , Push to Talk , conferencing etc. to their customer. Some of the real-time enterprise and service provider SIP applications currently being developed and deployed on the SIP Application server include IP Conferencing (voice & web), enterprise emergency notification, mobile conferencing, consumer/public VoIP and IM, IM client to PSTN calling, mobile video sharing, IM to Conferencing, mobile multiplayer gaming, toll-free calling, location based services, ring

Yashaswini Y K, IJRIT

37

back tones, remote TV/PVR manager, IPTV themed ringtones and smart call screening, and PoC (Push to talk over cellular). Currently lot of application development platforms & execution platforms for SIP are available in the market by leading providers like Avaya, IBM etc. The problems in the most platforms are that all these platforms are based on the stateful session model of SIP layers. So the application development on these platforms is very complex. Also the execution platform is very stateful due to this redundancy & load balancing is tougher on these platforms. Failure handling involves complex hot standby mechanisms affecting the seamless application flow. In our current work, we focus on these issues. The motivation for our work is to develop an application development & execution platform which is very simple to use & highly scalable without complex mechanism like hot standby. Our solution is built mostly on the stateless session model of the SIP at the stack layers, so it is easy to easily do failure handover, Also our solution relies on moving the state information wherever needed to the client place rather at the server. This allows for easy scalability of our platform thereby achieving superior performances.

2. Related Work In this section we detail the current application development solutions from commercial vendors and open sources. Cafe Sip hosts a number of open-source SIP projects. The projects are in the areas of SIP server framework, SIP applications and SIP test tools. These projects are aimed at providing free and open-source products for users and organizations developing or offering SIP applications and products. Cafe Sip provides Jip let, a framework for developing SIP server-side applications using the Java programming language. It provides a container for hosting “SIP servlets”. In concept, it is very similar to a Java Servlet (web application). Instead of using the HTTP protocol, a jiplet supports the SIP protocol. The Jiplet container can be run as a standalone application or it can be run as a service inside a J2EE container. The Jiplet Container has been tested extensively with the JBOSS. The problem with this application development platform is then it application development is on java & the developer must be java expert. Also it takes much time to develop applications in java & host on the platform. Aricent provides sip application development toolkit call SIP UA toolkit. Session Initiation Protocol (SIP) User Agent (UA) toolkit is a general-purpose SIP toolkit that enables users to develop any SIP based client/terminal, CPE, or network-core infrastructure application. Our SIP User Agent (UA) toolkit - a value-added offering built over the SIP stack layer - provides a robust, SIP processing-intensive platform that can be easily programmed to build SIP applications required for VoIP/IMS network deployments. By using a SIP toolkit as part of the application architecture, developers can isolate all protocol-level changes to within the scope of the toolkit layers. The Aricent SIP UA toolkit provides application developers with simple and abstracted call-level APIs that help them to develop innovative SIP applications rapidly. Developers need make only very minimal reallocate. The time additions to the application-toolkit interfaces, and yet can ensure that the application layer functionality remains unchanged. The problem is that still the platform is only for programmers not for users with little knowledge of programming language.

Yashaswini Y K, IJRIT

38

Fig 1: Architecture Radvision provides a SIP application server platform. The architecture of this platform is as above. The platform is complex & built on the stateful nature of SIP. So it becomes to scale the performance of the application & fault tolerance is based on complex hot – standby configuration.

3. Overview of proposed solution Our proposed solution consists of two important decisions. 3.1 For application development we make the decision to use building blocks which are very generic & can be used by the users without any programming knowledge. He has to drag & drop the building blocks, configure the parameters for the application service flow at each building block. By this mechanism we want to reduce the development time to hours instead of week & months to develop application. This way we make the application development a very simple process. 3.2 For application execution, we propose a method to transfer the application building blocks to stateless SIP constructs. We also provide mechanism to push the state information as much to the SIP clients instead of keeping it at the Server. This way the application can be scaled to any number of users & fault tolerance is easy to provide without any hot standby logic. BY moving the states from server to client based we are able to provide high performance to execution platform.

4. Details of proposed mechanism

4.1 Application Development Platform Our Application development is based on drag & drop of building blocks of application & connecting them for the service logic. The building blocks are purely protocol independent & user needs to know only the service logic to develop the application. This way we make the application development an easy process. Currently for the first version we provide the following building blocks. The building blocks are provided to realize the push to talk service.

Yashaswini Y K, IJRIT

39

1. LISTEN CALL 2. AUTHORIZE 3. INVITE CONFERENCE All these building blocks are connected in serial to realize the push to talk service. The application development platform generates a XML file about the service logic & provides the XML as the input the Application Execution Platform.

LISTEN 2 AUTHORIZE 3 INVITE CONFERENCE 8990111 99888012 89999912

4.2 Application Execution Platform Application execution platform execute the service logic mentioned in the XML file. The architecture of the application execution platform is given below.

Yashaswini Y K, IJRIT

40

Figure 2: Architecture of the application execution platform SIP Stack will handle the SIP messages to & from the network. Application execution platform is the service logic execution module, which executes the service flow. It invokes the Block to SIP converter based on the action block mentioned in the Application XML file. The core of the application execution platform is to convert the building blocks in the XML to the SIP constructs. We focus mainly on how to convert building blocks to state less sip constructs & pushing the state as much as possible to the client instead of keeping it at the execution platform. So this step makes the application execution platform stateless, failure of it will not affect the application, it can continue without any side effects. In other words we propose mechanism to make the application execution platform very light weight. Our mechanism to interact the application execution platform is to use SIP INFO messages. To initiate the Push to talk service, SIP user agent must send a SIP INFO message with the XML body decryption about the PTT session. The SIP INFO XML body must be following format 98886 89997 67778

Once this message is received, it triggers the LISTEN block in the service & listen block moves the service logic to next step which is AUTHORIZE. This block will verify if the caller has enough credentials to make the call. If enough credits are not available, then the call is rejected by sending the following response.

Yashaswini Y K, IJRIT

41

NOT ENOUGH CREDITS

If enough credits are available, the Application execution engine will send 200 OK response for INFO with following XML body

C12345 1778%^^ 212.22.33.45

In addition we also send INFO message to all the participants mentioned in the INVITE conference block. The XML body mentioned in the INFO message will be off following format

98878 C12345 1778%^^ 212.22.33.45

Yashaswini Y K, IJRIT

42

Now we have pushed all the state information of connecting to conference to the user client instead of at application execution engine. User client after accepting the INFO message will initiate the call to media server though regular SIP INVITE flow to connect in the conference. The conference parameters mentioned in SIP INFO body must be sent in the INVITE so that media server can connect all the parties in same conference bridge after authenticating the password

5. Performance Analysis We implemented the proposed mechanism & tested the performance of the solution on following hardware.

CPU

Dual core 2.1 GHZ

Memory

4GB

Number of instance of application engine

2

No of media server

1

No of parties

5

conference

OS

Ubuntu 11.1

Conference duration

3 min

Table 1 They calls are made by using SIPP performance measurement tool. We were able to see that system was able to achieve 200 calls for seconds. The same environment we tested the Jiplet sip server and it was able to handle only 120 calls for seconds for CPU usage of 60%. We measured the performance of both for various CPU usages and this is the observation.

CPU usage

60

70

80

Calls in our solution

200

220

245

Calls Jiplet

120

125

130

in

Table 2

Yashaswini Y K, IJRIT

43

6. Conclusion and enhancements

In this work, we have proposed a simple & scalable application development & execution platform. We have implemented the proof of concept of our platform & measure the performance of our solution. From the performance results, we find that our solution is able to process more calls than Jiplet even in moderate hardware. As the future work, we propose to implement some more functional blocks to cover more services using our platform.

7. References

1. Vonage. http://www.vonage.com, 2005. 2. Skype. http://www.skype.com, 2005. 3. Rosenberg J, Schulzrinne H, Camarillo G, Johnston AR, Peterson J, Sparks R, Handley M, Schooler E. SIP: session initiation protocol. RFC 3261, Internet Engineering Task Force, June 2002. 4. Campbell B, Rosenberg J, Schulzrinne H, Huitema C, Gurle D. Session initiation protocol (SIP) extension for instant messaging. RFC 3428, Internet Engineering Task Force, December 2002. 5. Campbell B, Mahy R, Jennings C. The message session rely protocol. SIMPLE Working Group Internet Draft,February 2005. 7. SJPhone. http://www.sjlabs.com, 2005. 8. Cisco IP Phones. http://www.cisco.com/en/US/products/hw/phones/ps379, 2005. 9. Koskelainen P, Schulzrinne H, Wu X. A SIP-based conference control framework. NOSSDAV, Miami Beach, FL, U.S.A., 2002. 10. Milandinovic I, Stadler J. Multiparty conference signaling using SIP. International Network Conference, Plymouth, U.K., 2002. 11. Singh A, Acharya A. Using session initiation protocol to build context-aware VoIP support for multiplayer networked games. NETGAMES, Portland, OR, U.S.A., 2004. 12. Akkawi A, Schaller S, Wellnitz O, Wolf L. A mobile gaming platform for the IMS. NETGAMES, Portland, OR, U.S.A., 2004. 13. Singh A, Mahadevan P, Acharya A, Shae Z. Design and implementation of SIP network and client services. ICCCN, Chicago, IL, U.S.A., 2004. Yashaswini Y K, IJRIT

44

14. Microsoft Live Communications Server. http://office.microsoft.com/en-us/FX011353441033.aspx, 2005. 15. JSR 32: JAIN SIP API Specification. http://jcp.org/aboutJava/communityprocess/final/jsr032/index.html. 16. Handley M, Jacobson V. SDP: session description protocol. RFC 2327, Internet Engineering Task Force, April 1998. 17. Roach A. Session initiation protocol (SIP)-specific event notification. RFC 3265, Internet Engineering Task Force, June 2002. 18. Convedia. http://www.convedia.com, 2003. 19. Rosenberg J, Peterson J, Schulzrinne H, Camarillo G. Best current practices for third party call control in SIP. RFC 3725, Internet Engineering Task Force, April 2004. 20. Singh A, Acharya A. Multiplayer networked gaming with the session initiation protocol. Elsevier Computer Networks 2005; 49(1):38–51. 21. Lotus Sametime. http://www.lotus.com/products/lotussametime.nsf/wdocs/about. 22. Deruelle J, Ranganathan M, Deruelle J, Montgomery D. Programmable active services for SIP. National Institutes of Standards and Technology Report, 2004. 23. Lennox J, Wu X, Schulzrinne H. CPL: a language for user control of internet telephony services. Internet Draft, October 2004. 24. Wu X, Schulzrinne H. Programmable end system services using SIP. IEEE International Conference on Communications, Anchorage, AL, U.S.A., 2003.

Yashaswini Y K, IJRIT

45