34358 - IMS Core emulator using SIPservlet 1.1

s101347 - Cosmin M. Caba

2

List of acronyms3GPP – Third Generation Partnership ProjectAJAX – Asynchronous JavascriptAPI – Application Programming InterfaceAS – Application Server

B2BUA – Back-to-Back User AgentCSCF – Call Session Control FunctionGW – GatewayHSS – Home Subscriber Service

HTML – HyperText Markup LanguageHTTP – Hypertext Transfer Protocol

IDE – Integrated Development EnvironmentiFC – initial Filter CriteriaIMS – IP Multimedia SubsystemIP – Internet Protocol

JCP – Java Community ProcessJPA – Java Persistence API

MGCF – Media GW Control FunctionMRF – Media Resource FunctionORM – Object-Relational MappingSCIM – Service Capability Interaction ManagerSIP – Session Initiation ProtocolSPI – Service Provider InterfaceSPT – Service Point TriggerUA – User Agent

UAC – User Agent ClientUAS – User Agent ServerUML – Unified Modeling LanguageURI – Uniform Resource Identifier

3

Contents

1 Introduction 5

2 Motivation 62.1 Usability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 Chosen technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 IP Multimedia Subsystem 83.1 IMS overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.2 Control and service layer interaction . . . . . . . . . . . . . . . . . . 93.3 Final functional requirements . . . . . . . . . . . . . . . . . . . . . . 10

4 SIP Servlet API 114.1 Leveraging SIP servlet technology . . . . . . . . . . . . . . . . . . . . 114.2 The Aplication Router . . . . . . . . . . . . . . . . . . . . . . . . . . 12

5 Application development 135.1 Initial Filter Criterias . . . . . . . . . . . . . . . . . . . . . . . . . . . 135.2 Software implementation . . . . . . . . . . . . . . . . . . . . . . . . . 14

5.2.1 Web component . . . . . . . . . . . . . . . . . . . . . . . . . . 155.2.2 SIP component . . . . . . . . . . . . . . . . . . . . . . . . . . 155.2.3 Custom application router component . . . . . . . . . . . . . 16

6 Testing 186.1 Part one . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186.2 Part two . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

7 Conclusion 22

4

1Introduction

Since the need for multimedia communications became apparent, network operatorsstarted to look for solutions to improve the provision of services to the end users, sothey could differentiate themselves from the competitors and increase their marketshare. An improvement in service provision might, for instance, be related to thecapability of supporting different end devices, different network access technologiesor even reducing the time to market of new and innovative services.

The IP Multimedia Subsystem is a platform able to provide access to multimediaservices 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 operatorsto seamlessly integrate third party services into their network emphasizing theseparation of concerns between the application (service) developer and the networkand service provider.

The present report aims at describing a possible implementation for an emulationenvironment of the IMS core using the SIP Servlet 1.1 API. The focus will be onthe integration with the service layer and the implementation captures only a thinstratum of functionality of the IMS core elements.

The structure of the report is as follows: the first chapter deals with the mo-tivation behind the chosen technology and the usability from a user perspective;the second part delves more into the minimum IMS functionality that needs to beimplemented; the third part gives a detailed overview of how SIP servlet API is usedto emulate the behavior of the IMS core entities; the fourth chapter presents the finalimplementation from a software development perspective; the fifth section shows thetesting methodology and the final part of the report conveys a general analysis andconclusion about the work being done and also possible future improvements.

5

2Motivation

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

2.1 UsabilityWith the advent of software technologies that allow rapid prototyping and de-

velopment of applications, the telecommunication services took the path towardsintegration with relatively new and object oriented languages. One such languageis Java, which became a competitive technology for the implementation of servicesin telecommunication. Given the widespread of Java and the strong demands forinnovative services in telecom industry, a strong bound was created between them,reinforced by the efforts of standardization bodies and also of the JCP(Java Com-munity Process) group which released API’s for integration of Java with lower leveltelecommunication mechanisms. SIP servlet is a Java API which permits develop-ment of services based on SIP protocol, hiding the complexity of the protocol. SinceIMS platform has at its core the SIP protocol, the "de facto" choice for developmentof services for IMS came to be the SIP servlet API.

Software developers working with SIP servlet API need a way to test their appli-cations. The requirements are that the applications experience the same interactionsas if they would be deployed in a real IMS environment. Here comes into place theproposed application. The purpose of it is to offer to a developer an environmentto deploy SIP servlet applications and execute actions similar to as having an IMSnetwork 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 theirapplications without the need for other actors or systems to intervene. The vision isthat programmers should be able, apart from building the services, to deploy themin the virtualized IMS network, set up IMS triggers according to service logic andfinally test the services from a user perspective.

The technology chosen for the implementation is SIP servlet 1.1 API. The mainreason behind this decision lies in the requirements for the project and the advantagesare going to be presented in the next chapters.

6

Figure 2.1: Use case scenarios

Next section presents the arguments for the chosen technology for the implemen-tation of the IMS emulation environment.

2.2 Chosen technologyThe development platform consists of Netbeans IDE, Sailfin application server

and Apache Derby database server. Netbeans allows easy integration of Sailfin andDerby database. Sailfin provides several containers for deploying applications butthe one of interest for the present project is the SIP converged container because itcan host both SIP and web applications.

Regarding the API’s, the most important are SIP serlvet, used to model the IMSbehavior and Java Persistence API 2.0 (JPA), used to access the database.

The implementation is limited to the basic functionality of IMS core leaving mostof the details for future work. Next chapter presents an overview of IMS networkand goes more in detail about the functional entities that need to be emulated.

7

3IP Multimedia Subsystem

In deciding what is the minimum required functionality for an emulation of IMScore one must look into the network topology and the functions of the entities. Themethodology used is to narrow down the functional requirements to a small set thatcan be implemented in the given amount of time with the given technology. Nextsections follow this methodology, each of them going one level lower towards the finalspecifications for the project.

3.1 IMS overviewFigure 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 integrationof the service and control layers of IMS. The entities that are shaded in Figure 3.1will have their functionality included in the final implementation.

On the service layer there are the application servers. They contain services andexecute the logic every time invoked by the CSCF(Call Session Control Function).

8

The HSS (Home Subscriber Server) is the database that stores information aboutusers and not only. The CSCF is the main entity in the IMS core. Its purpose isto trigger different services depending of the user subscription. This three entitiesmake 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 dealwith other aspects of IMS, outside of the scope of this project(e.g. interoperationwith other domains). Next section presents a more detailed overview of the chosenentities and how they interconnect with each other.

3.2 Control and service layer interactionIn 2001 3GPP (3rd Generation Partnership Project) introduced a new entity in

the IMS core : the SCIM (Service Capability Interaction Manager)[3]. The purposeof this entity is, as its name implies, to take care of the interaction of the CSCF withthe 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 locatedin HSS or any other database in the network. In later 3GPP releases, the SCIMhas been introduced as a functional entity belonging to the application server. TheSCIM therefore should manage the service chaining inside an application server. Stillthere is no specific standard describing how to implement such an entity.

Also as it can be noticed in Figure 3.2, there should be a management interfaceallowing the developer to set up IMS triggers for his services.

Because the platform used for the project is running on a virtual machine and allthe 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 finalrequirements for implementing the envisioned functionality.

3.3 Final functional requirementsFigure 3.3 captures the final requirements for the project. User A initiates a call to

User B. The INVITE request is first handled by the CSCF. This entity discovers thatit should proxy the request to the application server for service execution. Assumingthat User A has subscribed for services implemented in Application 1(APP1) andApplication 3 (APP3) and User B for APP2 and APP4, the SCIM will createthe service chain accordingly. It’s worth mentioning the concept of routing region.Some of the services make sense to be executed only when the subscribed user isinitiating a call therefore in the Originating region or only when it receives a callthus Terminating region. The SCIM and CSCF must pay attention to this conceptas well when building the service chain.

Figure 3.3: Final functional requirements

There is only one application server which has all the necessary applicationsdeployed in. This final design represents the thin layer of functionality that theapplication is going to implement. The services deployed in the application serverwill be only mockups, with no real purpose beside from showing that the servicechaining works as expected.

With all the requirements at hand, next chapter proceeds with describing howcan one use SIP servlet to develop the application.

10

4SIP Servlet API

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

4.1 Leveraging SIP servlet technologySIP 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 SIPservlet under a different light, leveraging it’s capabilities in order to emulate theaforementioned IMS functionality.

Looking back in the previous section one should notice that there are two mainrequirements in terms of functionality, that the final application must fulfil. Thefirst is embodied by CSCF entity and translates into the fact that the applicationmust route the requests for each user registered in the domain. This must be doneaccording to the iFC’s (initial Filter Criterias) established in the IMS. The secondrequirement is to realize the composition of the services similar to SCIM inside theapplication server.

The routing of requests could be easily realized with a stateful proxy or a B2BUA(Back-to-Back User Agent).

According to the final requirements, Figure 3.3, there is only one applicationserver running the services therefore the role of the emulated CSCF is greatlyreduced to that of proxying the initial request and the SCIM must further handlethe application composition.

In SIP servlet 1.0 specifications, application composition could be achieved using<servlet-mapping> element in the deployment descriptor. The downside of thisapproach is the inherent static behaviour, as the composition can be altered only byrewriting the deployment descriptor and restarting the server. This does not fit withthe requirement of having dynamic service composition according to the enablediFCs.

Learning from experience, the JCP group came up with a new concept in SIPservlet 1.1 specification, to allow for more flexibility when chaining the applications(services) inside the application server: Application Router (AR). Since thisrepresents the core of the application, a detailed description is given in the nextsection.

11

4.2 The Aplication RouterThe 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 whenrouting the incoming requests.

In order to understand how the application router works one must understandthe behaviour of the SIP container. Figure 4.1 [2] depicts the mechanism behindthe application router.

Figure 4.1: Application router

When receiving an initial SIP request the container must decide to which ap-plication to forward the request. If in version 1.0 this was done exclusively using<servlet-mapping> by checking each deployment descriptor sequentially and forwardto the first that matched, in 1.1 specification, the container cannot make this decisionon its own. Instead it makes a request to the application router to get the name ofthe application that has to receive the request. If one application contains multipleservlets 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 thecontainer in the decision point and the composition process is continued in the samemanner.

The application router can be implemented as complex as needed. There are nospecific restriction in this sense. To achieve a behaviour similar to IMS triggers, theAR must communicate with a database containing the iFCs for each subscriber.

In JSR 289 [4] there is a Default Application Router specified and Sailfin providesanother implementation : an Alphabetical Application Router which selects theapplications in alphabetical order. None of this matches the requirements for theproject therefore a new implementation will be given.

12

5Application development

This chapter captures the software implementation of the application in terms ofdatabase entities, classes, software modules etc. The first section clarifies what arethe iFCs and how are they represented in the database. The second section presentsthe software implementation.

5.1 Initial Filter CriteriasBefore 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 tomatch a request if it matches at least one of the SPTs of that iFC. Figure 5.1illustrates 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 profile.A service profile is meant to store information about the services that a user hassubscribed for, in the form of iFCs. Because a user may subscribe for several services,there is a one-to-many relationship between a service profile and the correspondingiFCs. Each iFCs has a set of SPTs associated. These hold detailed information thata request can be matched with. For simplicity, the present implementation routesthe request based only on the iFCs and does not do a deeper investigation upon theassociated SPTs.

Apart from the tables presented in Figure 5.1, the database contains the registrartable.

5.2 Software implementationFrom the software point of view, the final implementation contains three main

components: the first is represented by the back-end and front-end for the manage-ment interface, allowing for trigger set up;the second is the SIP part and the lastone 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 betweenIMS entities and software components since it is just an emulation. The goal is tohave an final application that behaves similar to IMS.

The final 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 appli-cation server (Sailfin) and it is not managed by any container, being an externalcomponent. Inside the converged container there is one application, named CSCF,containing SIP and HTTP servlets. The HTTP servlets along with other HTMLpages represent the web component. There are two SIP servlets. The first is theRegistrar (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 Sailfin to help for testing.The communication with the database is done using the JPA 2.0 ORM (ObjectRelational 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 first servlet SubscribeManager handles request for adding a user to thedomain and assigning services (iFCs) to each user. It is linked with two HTMLpages: AdminView.html and iFCView.html. In the figure it is also mentioned whatfields 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 listof active triggers for a user.

5.2.2 SIP component

The SIP component is comprised of the Registrar servlet which handles REGISTERrequests for the users and the Scscf servlet which handles INVITE requests.

The Scscf is implemented as a stateful proxy and has a limited purpose sincemost of the routing and service composition is done by the application router. Butfor the sake of similarity with IMS and maybe for future extensions it has beenincluded in the design.

15

5.2.3 Custom application router component

Because the new application router is different from any existing implementationit will be referred further in the report as Custom Router (CR).

The CR is implemented and packaged according to the SPI (Service ProviderInterface) pattern[2]. This requires the structure presented in Figure 5.4. The entrypoint is the javax.servlet.sip.ar.spi.SipApplicationRouterProvider file,located in theMETA-INF/services folder. This file contains the name of the class implementingSipApplicationRouterProvider interface which, for the present case, is CustomRouter-Provider.java. From this class the container is able to retrieve an instance of theCustomRouter 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 Cus-tomRouter class implements the SipApplicationRouter interface and overrides itsmethods. Apart from the inherited methods, the CustomRouter class also containsother methods that return data from database or help in the application compositionprocess. The composition of applications is mainly defined in the abstract class Appli-cationComposer. The CustomRouter relies on the logic of the ApplicationComposerto build the chain. The ApplicationComposer contains only information regarding thestate of the chain(current application, current region) but the applications are storedas String value types inside an ApplicationHolder instance. The ApplicationComposerhas two ApplicationHolder objects: originating (containing all the applications thatthe caller has subscribed to) and the terminating (containing all the applications thatthe callee has subscribed to). When the CustomRouter is invoked by the container toreturn next application in the chain, it makes another call to an ApplicationComposerobject (getNextApplication())and all the logic happens inside this method.

It must be mentioned that the Application Router has been designed as a statelessinstance. The only way it can store state information is by using a state info objectand pass it to the container between the calls. As mentioned, the ApplicationComposerstores state information therefore this object is passed to the container and retrievedevery time the CustomRouter needs to know where exactly to restore the chaining ofapplications.

16

Figure 5.5: UML diagram for CR

The interfaces ApplicationComposer and ApplicationHolder have only definedthe required methods but the actual implementation lies inside the SimpleApplica-tionComposer and SimpleApplicationHolder classes. This promotes code re-usabilitysince a different implementation may be provided for the interfaces, thus chang-ing the mechanism for the composition, without braking the functionality of theCustomRouter.

Next chapter describes the tests that were performed on the application.

17

6Testing

In order to show how the application works, SIPp tester has been used. Whenusing SIPp tester to send INVITE requests from the UAC (User Agent Client) tothe UAS (User Agent Server), default SIP URI-s are used in the requests. Theseare: 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 applicationsare deployed in Sailfin(applications A, B and C ). The proposed scenario will haveeach of the users (caller and callee) subscribed for a set of services. A first callis initiated showing the application chain. Then the callee is registered with anadditional service and the call is repeated. The chaining of the applications shouldbe modified accordingly. Next section describes the first part of the test.

6.1 Part oneFirst, each of the UAs (User Agents) is added to the domain through the web

interface (AdminView.html). Then the UAs are registered, using Netbeans’ integratedSIP Agent tool. Finally for the caller two applications are associated: A and Band for the callee only one : C. The first call is initiated using the SIPp tester.The output from the application server is shown further (unnecessary info has beendiscarded 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:5065S-CSCF : request : sip:service@127.0.0.1:5065S-CSCF: Proxying.(AppRouter)Routing Directive : CONTINUE(SimpleApplicationComposer : )nextSubscriberUri sip:sipp@127.0.0.1:5080B : request : sip:service@127.0.0.1:5065 INVITEB : Proxying.(AppRouter)Routing Directive : CONTINUE(SimpleApplicationComposer : )nextSubscriberUri sip:sipp@127.0.0.1:5080A : request : sip:service@127.0.0.1:5065A: Proxying.(AppRouter)Routing Directive : CONTINUE

18

(SimpleApplicationComposer : )nextSubscriberUri sip:service@127.0.0.1:5065C : request : sip:service@127.0.0.1:5065 INVITEC : Proxying.(AppRouter)Routing Directive : CONTINUE(SimpleApplicationComposer : )nextSubscriberUri sip:service@127.0.0.1:5065C: Got response:180 RingingA: Got response:180 RingingB: Got response:180 RingingS-CSCF: Got response:180 RingingC: Got response:200 OKA: Got response:200 OKB: Got response:200 OKS-CSCF: Got response:200 OKS-CSCF: Got BYE request:sip:service@127.0.0.1:5065 BYEB: Got BYE request:sip:service@127.0.0.1:5065 BYEA: Got BYE request:sip:service@127.0.0.1:5065 BYEC: Got BYE request:sip:service@127.0.0.1:5065 BYEC: Got response:200 OKA: Got response:200 OKB: Got response:200 OKS-CSCF: Got response:200 OK

As it can be noticed the order the applications are called is : S-CSCF, B, Aand C. It must be mentioned that the S-CSCF is called no matter if the users areregistered with any services since it represents the IMS core proxy. The first twoapplications B and A correspond to the caller and the order in which they arecalled is dictated by the priority field of the iFC in the database(see Figure 5.1).Application C is associated to the callee. The 200 OK response follows the reversechaining and this time everything is automatically handled by the container withoutthe help of the application router.

19

As a short summary for this part, the Custom Router performs its duties as itshould and the application composition follows the rules defined through the webinterface.

6.2 Part twoIn 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 theapplication chain. A lower value for the priority puts the corresponding applicationin a position closer to the start of the chain. A new call is initiated and the outputis 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:5065S-CSCF : request : sip:service@127.0.0.1:5065S-CSCF: Proxying.(AppRouter)Routing Directive : CONTINUE(SimpleApplicationComposer : )nextSubscriberUri sip:sipp@127.0.0.1:5080B : request : sip:service@127.0.0.1:5065 INVITEB : Proxying.(AppRouter)Routing Directive : CONTINUE(SimpleApplicationComposer : )nextSubscriberUri sip:sipp@127.0.0.1:5080A : request : sip:service@127.0.0.1:5065A: Proxying.(AppRouter)Routing Directive : CONTINUE(SimpleApplicationComposer : )nextSubscriberUri sip:service@127.0.0.1:5065C : request : sip:service@127.0.0.1:5065 INVITEC : Proxying.(AppRouter)Routing Directive : CONTINUE(SimpleApplicationComposer : )nextSubscriberUri sip:service@127.0.0.1:5065A : request : sip:service@127.0.0.1:5065A: Proxying.(AppRouter)Routing Directive : CONTINUE(SimpleApplicationComposer : )nextSubscriberUri sip:service@127.0.0.1:5065A: Got response:200 OKC: Got response:200 OKA: Got response:200 OKB: Got response:200 OKS-CSCF: Got response:200 OKS-CSCF: Got BYE request:

20

sip:service@127.0.0.1:5065 BYEB: Got BYE request:sip:service@127.0.0.1:5065 BYEA: Got BYE request:sip:service@127.0.0.1:5065 BYEC: Got BYE request:sip:service@127.0.0.1:5065 BYEA: Got BYE request:sip:service@127.0.0.1:5065 BYEA: Got response:200 OKC: Got response:200 OKA: Got response:200 OKB: Got response:200 OKS-CSCF: Got response:200 OK

According to the listing, the applications are called in the following order:S-CSCF, B, A, C and A.The newly added application, A, is located in the tail ofthe chain since the assigned value for the priority was higher than the one of thepriority of application C. The application composition process performed as expectedproving that it is possible to dynamically add services to users.

Apart from dynamic application composition, the Custom Router stores theapplication name in the database whenever a new application is deployed in Sailfinand deletes it when undeployed. This way it is aware of what applications areavailable 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 theservices that a user has subscribed for, the remaining of the report presents theconclusion and further analysis of the implemented software.

21

7Conclusion

It has been already mentioned that the present project is just an emulation andthere 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 shownin Chapter 6, the final implementation behaves similar to the core entities of IMS.From a software development perspective the code has been designed to supportre-usability and to be easy to extend to a more detailed or complex implementation.

The application is lacking mechanisms for validation of user input, databasevalidation and other additional mechanisms that would have made it more robust.But, since the purpose was only academic and the time was relatively limited, theseadditional mechanisms have been considered an unnecessary complication.

From the testing point of view, one may envision a more thoroughly test setupto exercise the applications capabilities. The test setup from Chapter 6, serves justas an argument to prove the goal has been achieved.

Even with the limitations mentioned above, the application supports integrationwith other SIP based applications similar to the IMS core, with the mention that theremust be only one application server containing all the deployed software components.

Regarding the future improvements, the implementation can be extended inmultiple ways. One might be to make it more robust by including validationmechanisms for the web part or other validation mechanism related to the databaseaccess. Also the SIP mechanisms may be improved by handling more methods inthe SIP requests. Now it only handles INVITE and REGISTER methods. Anotherway of improving may be to look into the possibility of having external routes, thismeans integration with other application servers.

The present application completely disregards the Proxy and Interrogating CSCFsfrom IMS since they are related to a multi-domain scenario which would have madethe emulation much more complex from the start.

This project has proved that SIP servlet API is a powerful technology giving thedevelopers the ability to create reach SIP based services for the IMS network. Alsothe project has exploited the application router feature of SIP servlet 1.1 which is arelatively 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 Kristoffer Gronowski. Understanding sip servlets 1.1. 2009.

[3] Christophe Gourraud. http://theimslantern.blogspot.com/, 2012.

[4] Mihir Kulkarni and Yannis Cosmadopoulos. Sip servlet specification, version 1.1.2008.

23