SIP SERVICES USING SIP SERVLET API THE INFOLINE SERVICE

Journal of Information, Control and Management Systems, Vol. 8, (2010), No.3 SIP SERVICES USING SIP SERVLET API THE INFOLINE SERVICE Pavel SEGEČ University of Žilina, Faculty of Management Science and Informatics, Slovak Republic e-mail: Pavel.Segec@fri.uniza.sk Abstract Nowadays, the Telecom industry has to quickly react to the dynamically changing market expectation. For this, it requires the means that would allow flexible development of new communication services. Among its major benefits, the SIP protocol offers is the ability to be used as a tool for creation of communication services. There are many different approaches to create a SIP service. In generally, all of them require the building block services providing network capabilities at a protocol level (SIP). The building block services are then extended by software programming functions or interfaces that are required for the development of main services. Following the basic service creation model, development of a SIP service means to extend SIP entities by a programmed logic (application), where the logic is responsible for providing a service with the expected feature. The SIP Servlet API, a popular Java application programming interface for SIP service development, is an example of such kind of interfaces. The SIP Servlet API provides feature rich and robust developing environments. It has been standardized as a technical specification of the Java Community Process (JCP) in JSR289. In this paper we describe the SIP Servlet API and using an example of a click2call service developed in the Department of Infocomm networks, we demonstrate the SIP Servlet API flexibility for developing converged communication services which integrate HTTP and SIP features. Keywords: SIP, SIP Servlet API, services, programming, click2call 1 INTRODUCTION Session Initiation Protocol (SIP) [1] is a text based signaling protocol developed to set up, modify and tear down multimedia sessions such as voice and video calls, instant messaging and the like over the Internet Protocol (IP). SIP is behind many popular communication platforms (Voice over IP (VoIP), instant messaging, presence,

2 number of the even pages is at left side Title of the paper, size 10 conferencing). It becomes an importing key technology in a process of network convergence. SIP was adopted as a session control protocol for the IMS (IP Multimedia Subsystem) [2] as well for the Next Generation Network standardized by ETSI [3]. The SIP architecture is based on the Internet popular client/server architecture model. SIP defines several logical entities with specific tasks. The entities can act either as endpoints or as servers. Endpoints, in general, are initiating SIP sessions. Servers, in general, handle SIP message exchange during a session initiated by endpoints. SIP endpoints are User Agent (UA), Back-to-back User Agent (B2BUA) and SIP gateways. SIP servers can act as Registrar servers, Proxy servers and Redirect servers. SIP implementation brings some other types of SIP servers with some special functions, for example location servers, application servers, subscriber servers, etc. SIP is a protocol, in which the endpoints send a request which is answered by a response generated by the servers. A session between the endpoints consists from sets of small number of text coded messages. Due to higher implementable administrative effort of this architecture, there are the approaches under the development on how to integrate Peer-2-peer (P2P) mechanisms into SIP without the need to implement complex SIP servers. An important aspect of the SIP success is the programmability of the SIP communication infrastructure for service creation and service delivery. SIP is based on the two most popular internet protocols, the HTTP (web) and SMTP (e-mail). This helps the SIP to become understandable and popular. SIP is offering many forms of programming new innovative services. Dedicated programming tools such as Call Processing Language - SIP CPL, Common Gateway Interface SIP CGI and many tools resulting from the process of integrating Java programming language and telecom world as SIP servlets, Java API for Integrated Networks - JAIN APIs and Parlay are very popular. In this paper, we focus on the SIP service creation approach using SIP Servlet API as a SIP dedicated programming tool. First we analyze the SIP Servlet API and next we provide information about a converged communication service developed using the SIP Servlet technology, the Infoline click2call service. 1.1 Programming SIP service Creation of SIP service usually means adding some additional program, or service logic that enhances functionality of a SIP entity. Generally, any arbitrary programming language can be used for this purpose. The logic is used to influence and to handle a specific SIP signaling message flow or just to react on special conditions triggered by special events (receiving a specific SIP message, a SIP header value, etc.). The main SIP specification [1] does not cover the issue of the placement of the service implementation; service logic can be added on the top of the endpoints and servers. In most cases the service is located on a server part of a SIP infrastructure. For service placement, any SIP server entities mentioned above can be used. In

Journal of Information, Control and Management Systems, Vol. 8, (2010), No.3 telecommunications or Service Provider (SP) environments special SIP servers dedicated for SIP services hosting, called SIP Application Servers (AS) have been developed.. The basic SIP service creation model supposes the extension of SIP server entities by service logic (application), where the logic communicates with the SIP server through an application programming interface (API) and utilizing SIP server network session control functionality. In the case of a special event, the SIP server is instructed to pass specific information to the logic. The logic makes a decision and instructs backward the SIP server about the actions it has to perform. The logic can be placed either in the SIP server itself, or in a separate, independent system. In the latter case the role of the API interface takes over a specialized protocol Remote Procedure Call (RPC) mechanism or distributing computing platform (CORBA, DCOM, etc.). A model that reuse a functionality of a programming interface allows that a service simple uses the underlying network control and signaling infrastructure and significantly simplifies a process of development and implementation of new communication services. This is allowed by mechanisms that use standardized service developing interfaces. The development of new communication services and applications is becoming simpler (from time, technology as well as economic points of view) and very close to the standard IT application development cycle. A couple of interfaces between service logic and SIP server have been defined; some of them are derived from the interfaces that are used for the development of web services. These interfaces should satisfy some design goals as service portability, robustness, simplicity, user friendliness, flexibility and extensibility [4]. The current set of standards includes SIP CGI, SIP-servlets, JAIN, Parlay/OSA and Parlay X, and CPL. Evaluating theirs pros and cons based on criteria as network capabilities, reference architecture, interface abstraction, suitability for third party developers, and easiness of use or industry support service, developers can choose up API on their needs [5]. There are many ways how to categorize SIP APIs. There are standardized APIs (SIP CGI, SIP-servlets, JAIN, Parlay, and CPL) and proprietary SIP APIs; however those provide lower portability of developed services. There are APIs which allow creation of services either by trusted users (SIP CGI, SIP-servlets, JAIN, Parlay) or by untrusted users (CPL). Another possible categorization is based on the level of abstraction that the API provides. A high level API hides (CPL) the SIP functionality of network more than a low level API (JAIN, SIP Servlet) [6]. 2 SIP SERVLET The SIP Servlet API, standardized in Java Community Process (JCP) [7] [8] defines a container-based programming model for creation SIP services similar to the HTTP Servlet API. SIP Servlet API is a Java API interface which extends the functions

4 number of the even pages is at left side Title of the paper, size 10 of a generic Java Servlet API. The HTTP Servlet API has been also derived from generic Java Servlets API. The SIP Servlet API allows SIP servers and UAs to create and implement SIP communication services by means of Java Servlets technology. The purpose of the SIP Servlet API is to provide a standardized platform for developing and delivering SIP based services. The SIP Servlet API defines interfaces, abstractions and mechanisms, which allow creation of the service logic (Fig. 1). Sip XML Servlet 1 Sip XML Servlet 1 Servlet 2 Servlet 2 Servlet 3 Application 1 Application 2 API API Container SIP Servlet AS Figure 1 SIP Servlet model. The SIP servlet is a Java application component which is managed by a SIP server (through its servlet container) and which performs SIP signaling. The service logic is provided as a servlet application consisting from one or more SIP servlets running a specific service function. On a SIP server, more services are usually realized. It is a SIP servlet (also called server engine) container that takes a decision on which applications (servlet) to invoke and in which order. The process is controlled by an occurrence of a specific SIP event (type of message, some header field value and so on). The container also manages the servlets lifecycle. The SIP servlet container is a part of an application server that can be built into a SIP server, or installed as an add-on component [8]. Once the SIP servlet is invoked, it interacts with SIP UAs by exchanging SIP request and SIP response messages through the servlet container over defined network listening points. The servlet is initialized as a process of the Java Virtual Machine (JVM). Until its lifecycle is finished (by a servlet container), servlets functions are used each time the service is called. Communications between the SIP servlet and the SIP server (its servlet container) is done by means of Java objects. Java objects are used for modeling SIP messages. Using objects enables that all parts of received SIP messages are provided to the SIP servlet. The Servlet application then

Journal of Information, Control and Management Systems, Vol. 8, (2010), No.3 performs all actions required to achieve a service behavior and instructs the SIP servlet container to perform the next actions (for example, proxying message, fork message, finish transaction, etc.). The SIP servlet may behave as an UAC (generation of SIP requests) or as a SIP server (serving SIP messages). The SIP servlet itself does not support statefull behavior; this feature is realized at a servlet container level. The servlet container supports both types of SIP processing, stateless as well as statefull. The SIP servlet container is a part of a SIP server and provides networking functions of the SIP server to SIP servlets (low level functions). The SIP servlet container manages network listen points (the combination of the transport protocol, the port number and the IP address). It receives and transmits the SIP traffic through them. In this way the SIP servlet may communicate through a network using the SIP. Servlet container maintains a lifecycle of SIP servlets. Based on servlet mapping, the container decides which servlet will be invoked and in which order. The rules are specified by the deployment descriptor (DTD). It is the SIP servlet container which provides servlet functionality to the SIP server. Like that the server is able to maintain services created by the servlet technology. SIP servlets technology was developed as an alternative to the SIP CGI technology. The main target was to avoid of SIP CGI limitations, the platform dependability of the SIP CGI scripts and a weak performance scalability of the SIP CGI. These restrictions were removed by an exclusive usage of Java development environment to create SIP Servlet API (and then services). Thus, the platform independence of SIP servlet services has been achieved. Using Java brings other advantages coming from the Java platform itself, i.e. the security, flexibility and many existing APIs (JDBC for database connectivity, JMF for media processing, JavaMail, JNDI for directory processing and so on). From the performance scalability point of view, the SIP servlet accesses the system resources more effectively than the SIP CGI. The first service call initiates and starts SIP servlets. They remain active and their functions may be reused whenever the service is called again. The Servlet remains active until its lifecycle is finished by the container. This is unlike to the SIP CGI, in which each service call starts a completely new process. New services can integrate multiple types of communications, such as telephony, web, mail, instant messaging, etc. To support the expectations there are different types of SIP Servlet container implementations. For example, a special type of converged SIP container that enables the deployment of applications that use SIP, HTTP Servlet API and other Java EE components like EJBs, webservices, messaging, etc. may be used. There are three different methods of SIP Servlet implementations [8]: Standalone SIP Servlet container, which provides SIP interface and hosts SIP Servlets only as the applications.

6 number of the even pages is at left side Title of the paper, size 10 SIP Servlets and HTTP Servlets container, in which SIP and HTTP servlets share the same context. This implementation is suitable for the creation of integrated web and SIP services. SIP and Java EE Convergence container. This implementation facilitates the use of SIP Servlet technology in conjunction with a more complex Java EE deployment model. Thanks to Java, the SIP Servlet technology allows creation of SIP services that use the same principles that are used for the web services development or development of other Java applications. Thus, the SIP Servlets may become very interesting platform for a wide community of Java web developers. The SIP Servlets are also suitable for the third party service developers. SIP Servlets technology is mainly focused on the area of enterprise application servers and J2EE developing platform. Here, it can bring some merits already known and used in development of converged applications and services. Even though the technology offers many interesting features, it is very complex and wholly based on Java. This can be objectively considered as weak points. 2.1 SIP servlet application servers The SIP Servlet AS represents Java EE framework used for the SIP services hosting. The SIP AS provides required SIP Servlet API for a logic implementation. Typical implementation of the SIP Application Server based on JSR 289 [8] is as the converged container that contents implementation of the HTTP Servlet API container and SIP Servlet API container allowing the creation of converged web and SIP services. Besides this the SIP AS can provides an additional APIs of the Java EE platform as for example Enterprise JavaBeans (EJB), Java Naming and Directory Interface (JNDI), Java Database Connectivity (JDBC), Java Message Service (JMS) and JavaMail, Java Persistence API (JPA). Presently there are several SIP AS implementations as: SailFin, a SIP servlet container extending popular GlassFish open source enterprise AS platform, developed under the lead of Sun Microsystems. Mobicents SIP Servlet AS, a subproject of the Mobicents open source VoIP platform. Cipango, a SIP Servlet extension to the Jetty HTTP Servlet container. Oracle Communications Converged Application server based on Oracle WebLogic server. WebSphere Application Server from IBM. WeSIP, a SIP and HTTP Converged Application Server built on top of OpenSER SIP platform.

Journal of Information, Control and Management Systems, Vol. 8, (2010), No.3 For the clic2call service example development, the open source solution Sailfin has been used. Sailfin [9] is the SIP Servlet AS project, based on robust and scalable SIP servlets technology on top of Java EE-based GlassFish application server. Sailfin is JSR289 compliant and provide high-availability and clustering features, while integrating with existing GlassFish services [9]. 3 CLICK2CALL SERVICE EXAMPLE THE INFOLINE SERVICE Click2call service is a perfect example of the SIP service creation flexibility and the proximity of SIP and HTTP protocols. Click2call is an example of new converged service, which allows initiation of a phone call from the web page. Our service example, the Infoline service, is kind of click2call service implemented over SIP servlet technology. The service has been developed by the Department of Information Networks at the University of Žilina. The infoline service is the redesign of the University infoline service [10] developed with the proprietary API and placed into a standardized SIP Servlet environment. The Infoline service will be implemented as a part of a live departmental IP network. The purpose of the Infoline service development was demonstrating the flexibility of SIP, especially SIP Servlet API, for HTTP and SIP service development. It is used to develop interesting, converged service for everyday use. Developed Infoline service allows establishing a SIP VoIP call through the web interface. The call is initiated among an initiator (caller or calling party) and the called party (callee). The phone call is initiated by a third party call control (3pcc) entity. 3pcc entity is instructed by the user (caller) through the web page. The call will be routed on a SIP address of a callee, i.e. web page owner. The Infoline service may be used in reverse order too. The service provides following features: Initiation of a call from the web page. Call availability management. Personal profile management. Management of failure calls and using of an alternative communication. Presence information provisioning. The main task of the service solution was to create a portable, scalable and platform independent SIP service, which integrate web HTTP part with SIP part. The solution of the Infoline service with it s AS implementation, have to allow a simple integration into an arbitrary SIP infrastructure (herein OpenSER and Asterisk SIP platform). Therefore the integrated communication AS platform with HTTP servlet and SIP servlet API has been selected. 3.1 Service components The Infoline service is built-up from several components. They can be categorized into two groups. The first group consists from those components of the

8 number of the even pages is at left side Title of the paper, size 10 communication infrastructure that allows the service realization, and that also allows a user to communicate with the service. They are independent from the main service. The group consists from the components over which is the web HTTP part and SIP signaling part of the communication infrastructure realized. They can be listed as follows (Fig. 2): A web browser, which provides the web interface allowing initialization of a call. A web server. It can be an arbitrary web server with web pages into which presence SIP information of a callee is inserted. SIP telephone for making a VoIP call. SIP infrastructure following the recommendations [1] with SIP presence service implemented. The Infoline service is using a callee SIP outbound proxy server serving the callee SIP domain. The service logic communicates with the SIP proxy using SIP protocol. Email server, which is used as alternative communication platform if the voice call was not successfully established. Web server Email server POP/IMAP POP/IMAP SMTP HTTP HTTP HTTP User (Caller) Computer with a web browser SIP telephone SIP Database SIP VoIP server SIP Application server IP Network SIP Computer with a web browser SIP telephone User (Callee) Figure 2 The infoline service components The main components of the service are as follows: SIP application server, which is hosting the main logic of the Infoline service. It is consisting from the main service application implemented through servlets technology using both, the web container used for http message processing and the SIP container used to process SIP message handling. The logic also includes the database part which allows consistent access to the database. Database, which store the service application data.

Journal of Information, Control and Management Systems, Vol. 8, (2010), No.3 3.2 Service description and operation Inside the service, we have three types of service users, a customer, an operator and an administrator. The administrator is a service user who when using the web interface may fully manage operator accounts of the service. The customer is a service user who cans browse through the web pages of an operator (personal, its employer or etc.). A web page contains the web content and the SIP presence information visualized by icons together with a web link by clicking on which a customer may initiate a call. Clicking on form a window is opened, into which the customer have to fill in his SIP address. After that a 3pcc entity is instructed to initiate a SIP call. The window is still opened to provide the call session information allowing call management or it provides a user with an alternative email communication if the call was not answered. The last kind of a user is an operator. The operator is a user with a valid service account. He may receive a SIP calls initiated by customers. Operator is able to personalize the service with managing time windows during which he is opened to receive calls from customers. The operator is able to change his personalized information. The operation of the service is based on a functional SIP infrastructure with a presence service on the operator site. On the customer site, a running SIP telephone is assumed only. Realization of the main service is logically divided into three parts, a presence subsystem, a click2call subsystem and a personal operator management subsystem. A presence subsystem allows real time visualization of the presence information of an operator (online, offline, on call, busy, away, and undefined). The presence information may be easily inserted into any kind of a web page. The personal operator management subsystem is available to operators only. It allows them service personalization. The click2call subsystem is the main part of the Infoline service. It is necessary for a call establishment. It also provides all functions required for correct service processing such as a SIP address consistency checking, operator status and call availability checking, call initiation through the SIP 3pcc entity, call management and alternative communication offering. The subsystem is further divided on the SIP signaling part and the web part. The signaling part is responsible for SIP message handling during the call session and is realized as a third party call control mechanism (3pcc) establishing two way call among the 3pcc and customer and among 3pcc and operator. The web part provides necessary function for a web call initiation. 4 CONCLUSION The Infoline service is a good example of a new converged communication service, which integrates telephone and web services into a new one. The Infoline service provides their users with a number of interesting features. Using the SIP servlet API and careful component selection the service is portable and platform independent, easily integrable into an arbitrary existing web and SIP communication environments. The service is using a basic SIP call service extended by a presence feature using SIMPLE technology for status visualization. Except SIP servlet part, the service is

10 number of the even pages is at left side Title of the paper, size 10 using modern web technologies of real time data presentation, which allows their users call monitoring and handling through the web interface. REFERENCES [1] ROSENBERG, J., SCHULZRINNE, H., CAMARILLO, G., JOHNSTON, A., PETERSON, J., SPARKS, R., HANDLEY, M., SCHOOLER, E.: SIP: Session Initiation Protocol, RFC 3261, July 2002 [2] http://www.3gpp.org [3] http://portal.etsi.org/portal_common/home.asp [4] HELEN J. WANG, ASCAN MORLANG, FREDDY MANG, ANTHONY D. JOSEPH, RANDY H. KATZ,: A Service Creation Model for Integrated Communication Systems on the Internet, INFOCOM 2001 [5] KRYVINSKA, N., STRAUSS, CH., AUER, L., ZINTERHOF, P.: Conceptual framework for services creation/development environment in telecom domain, International Conference on Information Integration and web-based Applications and Services, iiwas 2008, Linz, Austria, ISBN:978-1-60558-349- 5 [6] CHRIGHTON, C.,LONG, D. T., PAGE, D. C.: JAIN SLEE vs SIP Servlet Which is the Best Choice for an IMS Application Server?, Australasian Telecommunication Networks and Applications Conference, 2007, Christchurch, New Zeland [7] KRISTENSEN, A.: SIP Servlet API Version 1.0, February 2003 [8] COSMADOPOULOS, Y., KULKARNI, M.: SIP Servlet Specification, version 1.1, 242 s., JSR 289 Expert Group, JSR-000289 Final Release, 2008 [9] Sailfin SIP Servlet project, https://sailfin.dev.java.net/ [10] KOVÁČIKOVÁ, T., SEGEČ, P.: University Infoline Service - Internet telephony for interactive communication in e-learning, In: Learning Technology, publication of IEEE Computer Society. - ISSN 1438-0625. - Volume 5, Issue 1 (2003), p. 1-46.