34358 - IMS Core emulator using SIP servlet 1.

s101347 - Cosmin M. Caba

List of acronyms
3GPP AJAX API AS B2BUA CSCF GW HSS HTML HTTP IDE iFC IMS IP JCP JPA MGCF MRF ORM SCIM SIP SPI SPT UA UAC UAS UML URI Third Generation Partnership Project Asynchronous Javascript Application Programming Interface Application Server Back-to-Back User Agent Call Session Control Function Gateway Home Subscriber Service HyperText Markup Language Hypertext Transfer Protocol Integrated Development Environment initial Filter Criteria IP Multimedia Subsystem Internet Protocol Java Community Process Java Persistence API Media GW Control Function Media Resource Function Object-Relational Mapping Service Capability Interaction Manager Session Initiation Protocol Service Provider Interface Service Point Trigger User Agent User Agent Client User Agent Server Unied Modeling Language Uniform Resource Identier

Contents

1 Introduction 2 Motivation 2.1 Usability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Chosen technology . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5 6 6 7

3 IP Multimedia Subsystem 8 3.1 IMS overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2 Control and service layer interaction . . . . . . . . . . . . . . . . . . 9 3.3 Final functional requirements . . . . . . . . . . . . . . . . . . . . . . 10 4 SIP Servlet API 11 4.1 Leveraging SIP servlet technology . . . . . . . . . . . . . . . . . . . . 11 4.2 The Aplication Router . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5 Application development 5.1 Initial Filter Criterias . . . 5.2 Software implementation . 5.2.1 Web component . . 5.2.2 SIP component . . 5.2.3 Custom application 13 13 14 15 15 16

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . router component

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

6 Testing 18 6.1 Part one . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6.2 Part two . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 7 Conclusion 22

Introduction

Since the need for multimedia communications became apparent, network operators started to look for solutions to improve the provision of services to the end users, so they could dierentiate themselves from the competitors and increase their market share. An improvement in service provision might, for instance, be related to the capability of supporting dierent end devices, dierent network access technologies or even reducing the time to market of new and innovative services. The IP Multimedia Subsystem is a platform able to provide access to multimedia services from any type of end device. Because it is comprised of IP based technologies, it is agnostic to the type of access network. IMS represents the solution for operators to seamlessly integrate third party services into their network emphasizing the separation of concerns between the application (service) developer and the network and service provider. The present report aims at describing a possible implementation for an emulation environment of the IMS core using the SIP Servlet 1.1 API. The focus will be on the integration with the service layer and the implementation captures only a thin stratum of functionality of the IMS core elements. The structure of the report is as follows: the rst chapter deals with the motivation behind the chosen technology and the usability from a user perspective; the second part delves more into the minimum IMS functionality that needs to be implemented; the third part gives a detailed overview of how SIP servlet API is used to emulate the behavior of the IMS core entities; the fourth chapter presents the nal implementation from a software development perspective; the fth section shows the testing methodology and the nal part of the report conveys a general analysis and conclusion about the work being done and also possible future improvements.

Motivation
This chapter gives an idea about why it might be necessary to have an emulation of the IMS core and what are the resources for this project from the technological point of view. The rst section presents a possible use case scenario.

2.1

Usability

With the advent of software technologies that allow rapid prototyping and development of applications, the telecommunication services took the path towards integration with relatively new and object oriented languages. One such language is Java, which became a competitive technology for the implementation of services in telecommunication. Given the widespread of Java and the strong demands for innovative services in telecom industry, a strong bound was created between them, reinforced by the eorts of standardization bodies and also of the JCP(Java Community Process) group which released APIs for integration of Java with lower level telecommunication mechanisms. SIP servlet is a Java API which permits development of services based on SIP protocol, hiding the complexity of the protocol. Since IMS platform has at its core the SIP protocol, the "de facto" choice for development of services for IMS came to be the SIP servlet API. Software developers working with SIP servlet API need a way to test their applications. The requirements are that the applications experience the same interactions as if they would be deployed in a real IMS environment. Here comes into place the proposed application. The purpose of it is to oer to a developer an environment to deploy SIP servlet applications and execute actions similar to as having an IMS network at hand. Figure 2.1 illustrates the shift from traditional use case to the new approach. This may prove to be very helpful for developers since they can thoroughly test their applications without the need for other actors or systems to intervene. The vision is that programmers should be able, apart from building the services, to deploy them in the virtualized IMS network, set up IMS triggers according to service logic and nally test the services from a user perspective. The technology chosen for the implementation is SIP servlet 1.1 API. The main reason behind this decision lies in the requirements for the project and the advantages are going to be presented in the next chapters.

Figure 2.1: Use case scenarios

Next section presents the arguments for the chosen technology for the implementation of the IMS emulation environment.

2.2

Chosen technology

The development platform consists of Netbeans IDE, Sailn application server and Apache Derby database server. Netbeans allows easy integration of Sailn and Derby database. Sailn provides several containers for deploying applications but the one of interest for the present project is the SIP converged container because it can host both SIP and web applications. Regarding the APIs, the most important are SIP serlvet, used to model the IMS behavior and Java Persistence API 2.0 (JPA), used to access the database. The implementation is limited to the basic functionality of IMS core leaving most of the details for future work. Next chapter presents an overview of IMS network and goes more in detail about the functional entities that need to be emulated.

IP Multimedia Subsystem

In deciding what is the minimum required functionality for an emulation of IMS core one must look into the network topology and the functions of the entities. The methodology used is to narrow down the functional requirements to a small set that can be implemented in the given amount of time with the given technology. Next sections follow this methodology, each of them going one level lower towards the nal specications for the project.

3.1

IMS overview

Figure 3.1 depicts the most important entities of an IMS network. The interfaces are not mentioned in the picture since it only serves as a high level view.

Figure 3.1: IMS topological architecture(basic overview)

As previously mentioned the focus of this project is going to be on the integration of the service and control layers of IMS. The entities that are shaded in Figure 3.1 will have their functionality included in the nal implementation. On the service layer there are the application servers. They contain services and execute the logic every time invoked by the CSCF(Call Session Control Function). 8

The HSS (Home Subscriber Server) is the database that stores information about users and not only. The CSCF is the main entity in the IMS core. Its purpose is to trigger dierent services depending of the user subscription. This three entities make the objective of the project, when looking at IMS from this level. The entities left aside do not directly relate with the requirements as they deal with other aspects of IMS, outside of the scope of this project(e.g. interoperation with other domains). Next section presents a more detailed overview of the chosen entities and how they interconnect with each other.

3.2

Control and service layer interaction

In 2001 3GPP (3rd Generation Partnership Project) introduced a new entity in the IMS core : the SCIM (Service Capability Interaction Manager)[3]. The purpose of this entity is, as its name implies, to take care of the interaction of the CSCF with the service layer, namely application servers.

Figure 3.2: Control - service layer interaction (detailed overview)

In Figure 3.2 is suggested that the SCIM can base its logic on data located in HSS or any other database in the network. In later 3GPP releases, the SCIM has been introduced as a functional entity belonging to the application server. The SCIM therefore should manage the service chaining inside an application server. Still there is no specic standard describing how to implement such an entity. Also as it can be noticed in Figure 3.2, there should be a management interface allowing the developer to set up IMS triggers for his services. Because the platform used for the project is running on a virtual machine and all the testing must be done using the loopback interface, for the ease of development, 9

there will be only one application server considered. Next section describes the nal requirements for implementing the envisioned functionality.

3.3

Final functional requirements

Figure 3.3 captures the nal requirements for the project. User A initiates a call to User B. The INVITE request is rst handled by the CSCF. This entity discovers that it should proxy the request to the application server for service execution. Assuming that User A has subscribed for services implemented in Application 1(APP1) and Application 3 (APP3) and User B for APP2 and APP4, the SCIM will create the service chain accordingly. Its worth mentioning the concept of routing region. Some of the services make sense to be executed only when the subscribed user is initiating a call therefore in the Originating region or only when it receives a call thus Terminating region. The SCIM and CSCF must pay attention to this concept as well when building the service chain.

Figure 3.3: Final functional requirements

There is only one application server which has all the necessary applications deployed in. This nal design represents the thin layer of functionality that the application is going to implement. The services deployed in the application server will be only mockups, with no real purpose beside from showing that the service chaining works as expected. With all the requirements at hand, next chapter proceeds with describing how can one use SIP servlet to develop the application.

10

SIP Servlet API

This chapter presents details about the SIP servlet API which is the corner stone of the application. The rst section argues about possible solutions and introduces the new concept of Application Router. The second section shows a more detailed view of this new concept and how can it be used in the application.

4.1

Leveraging SIP servlet technology

SIP Servlet is a relatively new technology for building SIP based applications. The main target is to be used for the service layer in IMS. The present project puts SIP servlet under a dierent light, leveraging its capabilities in order to emulate the aforementioned IMS functionality. Looking back in the previous section one should notice that there are two main requirements in terms of functionality, that the nal application must full. The rst is embodied by CSCF entity and translates into the fact that the application must route the requests for each user registered in the domain. This must be done according to the iFCs (initial Filter Criterias) established in the IMS. The second requirement is to realize the composition of the services similar to SCIM inside the application server. The routing of requests could be easily realized with a stateful proxy or a B2BUA (Back-to-Back User Agent). According to the nal requirements, Figure 3.3, there is only one application server running the services therefore the role of the emulated CSCF is greatly reduced to that of proxying the initial request and the SCIM must further handle the application composition. In SIP servlet 1.0 specications, application composition could be achieved using <servlet-mapping> element in the deployment descriptor. The downside of this approach is the inherent static behaviour, as the composition can be altered only by rewriting the deployment descriptor and restarting the server. This does not t with the requirement of having dynamic service composition according to the enabled iFCs. Learning from experience, the JCP group came up with a new concept in SIP servlet 1.1 specication, to allow for more exibility when chaining the applications (services) inside the application server: Application Router (AR). Since this represents the core of the application, a detailed description is given in the next section. 11

4.2

The Aplication Router

The application router is a software entity which must be deployed in the application server and whose purpose is to help the SIP container in taking decisions when routing the incoming requests. In order to understand how the application router works one must understand the behaviour of the SIP container. Figure 4.1 [2] depicts the mechanism behind the application router.

Figure 4.1: Application router

When receiving an initial SIP request the container must decide to which application to forward the request. If in version 1.0 this was done exclusively using <servlet-mapping> by checking each deployment descriptor sequentially and forward to the rst that matched, in 1.1 specication, the container cannot make this decision on its own. Instead it makes a request to the application router to get the name of the application that has to receive the request. If one application contains multiple servlets the selection of the servlet is made based on the deployment descriptor. After the service logic of the application is executed the request arrives back to the container in the decision point and the composition process is continued in the same manner. The application router can be implemented as complex as needed. There are no specic restriction in this sense. To achieve a behaviour similar to IMS triggers, the AR must communicate with a database containing the iFCs for each subscriber. In JSR 289 [4] there is a Default Application Router specied and Sailn provides another implementation : an Alphabetical Application Router which selects the applications in alphabetical order. None of this matches the requirements for the project therefore a new implementation will be given. 12

Application development
This chapter captures the software implementation of the application in terms of database entities, classes, software modules etc. The rst section claries what are the iFCs and how are they represented in the database. The second section presents the software implementation.

5.1

Initial Filter Criterias

Before proceeding with explanations about the database schemas it must be mentioned that everything was designed to extend the already implemented registrar (also regarding the database table). An iFC is the IMS equivalent of a detection point from Intelligent Networks. Every time a request matches an iFC, it is forwarded to the corresponding service. An iFC is comprised of several Service Point Triggers(SPTs). The iFC is said to match a request if it matches at least one of the SPTs of that iFC. Figure 5.1 illustrates the database schema for the iFCs(as described in [1]).

Figure 5.1: Database schema

13

When added to the IMS domain each user is associated with a service prole. A service prole is meant to store information about the services that a user has subscribed for, in the form of iFCs. Because a user may subscribe for several services, there is a one-to-many relationship between a service prole and the corresponding iFCs. Each iFCs has a set of SPTs associated. These hold detailed information that a request can be matched with. For simplicity, the present implementation routes the request based only on the iFCs and does not do a deeper investigation upon the associated SPTs. Apart from the tables presented in Figure 5.1, the database contains the registrar table.

5.2

Software implementation

From the software point of view, the nal implementation contains three main components: the rst is represented by the back-end and front-end for the management interface, allowing for trigger set up;the second is the SIP part and the last one is the application router which deals with the service composition. It must be mentioned that it is not possible to have a one-to-one mapping between IMS entities and software components since it is just an emulation. The goal is to have an nal application that behaves similar to IMS. The nal design of the application is depicted in Figure 5.2

Figure 5.2: Final software architecture

As previously mentioned, the application router must be deployed in the application server (Sailn) and it is not managed by any container, being an external component. Inside the converged container there is one application, named CSCF, containing SIP and HTTP servlets. The HTTP servlets along with other HTML pages represent the web component. There are two SIP servlets. The rst is the Registrar (reused from the examples given at the course) and the second is the Scscf. They represent the SIP component. 14

There are also other SIP based applications deployed in Sailn to help for testing. The communication with the database is done using the JPA 2.0 ORM (Object Relational Mapping). From a web perspective, the communication is based on HTTP. The remaining of the chapter describe each of the components.

5.2.1

Web component

Figure 5.3 shows the architecture of the web component.

Figure 5.3: Web component

The rst servlet SubscribeManager handles request for adding a user to the domain and assigning services (iFCs) to each user. It is linked with two HTML pages: AdminView.html and iFCView.html. In the gure it is also mentioned what elds can be accessed by each of the web pages. The second servlet, ShowTriggers, is linked with the HTML page TriggerView.html and they both serve to show a list of active triggers for a user.

5.2.2

SIP component

The SIP component is comprised of the Registrar servlet which handles REGISTER requests for the users and the Scscf servlet which handles INVITE requests. The Scscf is implemented as a stateful proxy and has a limited purpose since most of the routing and service composition is done by the application router. But for the sake of similarity with IMS and maybe for future extensions it has been included in the design. 15

5.2.3

Custom application router component

Because the new application router is dierent from any existing implementation it will be referred further in the report as Custom Router (CR). The CR is implemented and packaged according to the SPI (Service Provider Interface) pattern[2]. This requires the structure presented in Figure 5.4. The entry point is the javax.servlet.sip.ar.spi.SipApplicationRouterProvider le,located in the META-INF/services folder. This le contains the name of the class implementing SipApplicationRouterProvider interface which, for the present case, is CustomRouterProvider.java. From this class the container is able to retrieve an instance of the CustomRouter and use it as described in the previous chapter.

Figure 5.4: Package structure

Figure 5.5 shows the UML class diagram for the CustomRouter. The CustomRouter class implements the SipApplicationRouter interface and overrides its methods. Apart from the inherited methods, the CustomRouter class also contains other methods that return data from database or help in the application composition process. The composition of applications is mainly dened in the abstract class ApplicationComposer. The CustomRouter relies on the logic of the ApplicationComposer to build the chain. The ApplicationComposer contains only information regarding the state of the chain(current application, current region) but the applications are stored as String value types inside an ApplicationHolder instance. The ApplicationComposer has two ApplicationHolder objects: originating (containing all the applications that the caller has subscribed to) and the terminating (containing all the applications that the callee has subscribed to). When the CustomRouter is invoked by the container to return next application in the chain, it makes another call to an ApplicationComposer object (getNextApplication())and all the logic happens inside this method. It must be mentioned that the Application Router has been designed as a stateless instance. The only way it can store state information is by using a state info object and pass it to the container between the calls. As mentioned, the ApplicationComposer stores state information therefore this object is passed to the container and retrieved every time the CustomRouter needs to know where exactly to restore the chaining of applications. 16

Figure 5.5: UML diagram for CR

The interfaces ApplicationComposer and ApplicationHolder have only dened the required methods but the actual implementation lies inside the SimpleApplicationComposer and SimpleApplicationHolder classes. This promotes code re-usability since a dierent implementation may be provided for the interfaces, thus changing the mechanism for the composition, without braking the functionality of the CustomRouter. Next chapter describes the tests that were performed on the application.

17

Testing
In order to show how the application works, SIPp tester has been used. When using SIPp tester to send INVITE requests from the UAC (User Agent Client) to the UAS (User Agent Server), default SIP URI-s are used in the requests. These are: sip:sipp@127.0.0.1:5080 (for UAC) and sip:service@127.0.0.1:5065 (for UAS), if ports 5080 and 5065 are used. In order to be able to create an application chain, several mockup applications are deployed in Sailn(applications A, B and C ). The proposed scenario will have each of the users (caller and callee) subscribed for a set of services. A rst call is initiated showing the application chain. Then the callee is registered with an additional service and the call is repeated. The chaining of the applications should be modied accordingly. Next section describes the rst part of the test.

6.1

Part one

First, each of the UAs (User Agents) is added to the domain through the web interface (AdminView.html). Then the UAs are registered, using Netbeans integrated SIP Agent tool. Finally for the caller two applications are associated: A and B and for the callee only one : C. The rst call is initiated using the SIPp tester. The output from the application server is shown further (unnecessary info has been discarded to keep the listing smaller): (AppRouter)Routing Directive : NEW (AppRouter)Call from : sip:sipp@127.0.0.1:5080 (AppRouter)Call to : sip:service@127.0.0.1:5065 S-CSCF : request : sip:service@127.0.0.1:5065 S-CSCF: Proxying. (AppRouter)Routing Directive : CONTINUE (SimpleApplicationComposer : )nextSubscriberUri sip:sipp@127.0.0.1:5080 B : request : sip:service@127.0.0.1:5065 INVITE B : Proxying. (AppRouter)Routing Directive : CONTINUE (SimpleApplicationComposer : )nextSubscriberUri sip:sipp@127.0.0.1:5080 A : request : sip:service@127.0.0.1:5065 A: Proxying. (AppRouter)Routing Directive : CONTINUE 18

(SimpleApplicationComposer : )nextSubscriberUri sip:service@127.0.0.1:5065 C : request : sip:service@127.0.0.1:5065 INVITE C : Proxying. (AppRouter)Routing Directive : CONTINUE (SimpleApplicationComposer : )nextSubscriberUri sip:service@127.0.0.1:5065 C: Got response: 180 Ringing A: Got response: 180 Ringing B: Got response: 180 Ringing S-CSCF: Got response: 180 Ringing C: Got response: 200 OK A: Got response: 200 OK B: Got response: 200 OK S-CSCF: Got response: 200 OK S-CSCF: Got BYE request: sip:service@127.0.0.1:5065 BYE B: Got BYE request: sip:service@127.0.0.1:5065 BYE A: Got BYE request: sip:service@127.0.0.1:5065 BYE C: Got BYE request: sip:service@127.0.0.1:5065 BYE C: Got response: 200 OK A: Got response: 200 OK B: Got response: 200 OK S-CSCF: Got response: 200 OK As it can be noticed the order the applications are called is : S-CSCF, B, A and C. It must be mentioned that the S-CSCF is called no matter if the users are registered with any services since it represents the IMS core proxy. The rst two applications B and A correspond to the caller and the order in which they are called is dictated by the priority eld of the iFC in the database(see Figure 5.1). Application C is associated to the callee. The 200 OK response follows the reverse chaining and this time everything is automatically handled by the container without the help of the application router. 19

As a short summary for this part, the Custom Router performs its duties as it should and the application composition follows the rules dened through the web interface.

6.2

Part two

In this section application A is added to the chain on behalf of the callee, with a higher value for the priority than application C which already belongs to the application chain. A lower value for the priority puts the corresponding application in a position closer to the start of the chain. A new call is initiated and the output is shown next : (AppRouter)Routing Directive : NEW (AppRouter)Call from : sip:sipp@127.0.0.1:5080 (AppRouter)Call to : sip:service@127.0.0.1:5065 S-CSCF : request : sip:service@127.0.0.1:5065 S-CSCF: Proxying. (AppRouter)Routing Directive : CONTINUE (SimpleApplicationComposer : )nextSubscriberUri sip:sipp@127.0.0.1:5080 B : request : sip:service@127.0.0.1:5065 INVITE B : Proxying. (AppRouter)Routing Directive : CONTINUE (SimpleApplicationComposer : )nextSubscriberUri sip:sipp@127.0.0.1:5080 A : request : sip:service@127.0.0.1:5065 A: Proxying. (AppRouter)Routing Directive : CONTINUE (SimpleApplicationComposer : )nextSubscriberUri sip:service@127.0.0.1:5065 C : request : sip:service@127.0.0.1:5065 INVITE C : Proxying. (AppRouter)Routing Directive : CONTINUE (SimpleApplicationComposer : )nextSubscriberUri sip:service@127.0.0.1:5065 A : request : sip:service@127.0.0.1:5065 A: Proxying. (AppRouter)Routing Directive : CONTINUE (SimpleApplicationComposer : )nextSubscriberUri sip:service@127.0.0.1:5065 A: Got response: 200 OK C: Got response: 200 OK A: Got response: 200 OK B: Got response: 200 OK S-CSCF: Got response: 200 OK S-CSCF: Got BYE request: 20

sip:service@127.0.0.1:5065 B: Got BYE request: sip:service@127.0.0.1:5065 A: Got BYE request: sip:service@127.0.0.1:5065 C: Got BYE request: sip:service@127.0.0.1:5065 A: Got BYE request: sip:service@127.0.0.1:5065 A: Got response: 200 OK C: Got response: 200 OK A: Got response: 200 OK B: Got response: 200 OK S-CSCF: Got response: 200 OK

BYE BYE BYE BYE BYE

According to the listing, the applications are called in the following order:SCSCF, B, A, C and A.The newly added application, A, is located in the tail of the chain since the assigned value for the priority was higher than the one of the priority of application C. The application composition process performed as expected proving that it is possible to dynamically add services to users. Apart from dynamic application composition, the Custom Router stores the application name in the database whenever a new application is deployed in Sailn and deletes it when undeployed. This way it is aware of what applications are available to be added in the service composition. Since it has been proven that the application behaves similar to the IMS core, allowing for dynamic set up of triggers and routing the SIP requests according the services that a user has subscribed for, the remaining of the report presents the conclusion and further analysis of the implemented software.

21

Conclusion

It has been already mentioned that the present project is just an emulation and there is no one-to-one mapping between IMS functionality and SIP serlvet. The main purpose of the project has been reached, in a sense that, as shown in Chapter 6, the nal implementation behaves similar to the core entities of IMS. From a software development perspective the code has been designed to support re-usability and to be easy to extend to a more detailed or complex implementation. The application is lacking mechanisms for validation of user input, database validation and other additional mechanisms that would have made it more robust. But, since the purpose was only academic and the time was relatively limited, these additional mechanisms have been considered an unnecessary complication. From the testing point of view, one may envision a more thoroughly test setup to exercise the applications capabilities. The test setup from Chapter 6, serves just as an argument to prove the goal has been achieved. Even with the limitations mentioned above, the application supports integration with other SIP based applications similar to the IMS core, with the mention that there must be only one application server containing all the deployed software components. Regarding the future improvements, the implementation can be extended in multiple ways. One might be to make it more robust by including validation mechanisms for the web part or other validation mechanism related to the database access. Also the SIP mechanisms may be improved by handling more methods in the SIP requests. Now it only handles INVITE and REGISTER methods. Another way of improving may be to look into the possibility of having external routes, this means integration with other application servers. The present application completely disregards the Proxy and Interrogating CSCFs from IMS since they are related to a multi-domain scenario which would have made the emulation much more complex from the start. This project has proved that SIP servlet API is a powerful technology giving the developers the ability to create reach SIP based services for the IMS network. Also the project has exploited the application router feature of SIP servlet 1.1 which is a relatively new feature and there is very little previous work related to it.

22

Bibliography
[1] 3GPP. Ts 29.228 v11.3.0. 2012. [2] Chris Boulton and Kristoer Gronowski. Understanding sip servlets 1.1. 2009. [3] Christophe Gourraud. http://theimslantern.blogspot.com/, 2012. [4] Mihir Kulkarni and Yannis Cosmadopoulos. Sip servlet specication, version 1.1. 2008.

23