An IMS testbed for SIP applications Cosmin Caba José Soler {cosm,joss}@fotonik.dtu.dk Networks Technology and Service Platforms

Agenda Problem background + solutions IMS service composition and triggering SIP Servlet Design decisions Implementation Testing methodology Conclusions

Problem background The work has been done as a MSc thesis project. Started during a course in programming services for NGN. The students should execute their SIP applications within a realistic network context.

Possible solutions for app. testing SIPp testing tool (SIP user agent) Good UA: custom SIP requests. Limited: test single application, no service composition, no network context. Open IMS Core Complete implementation of IMS CSCFs. Increased complexity, out of scope of the intented course.

Proposed solution Build a simple emulation for the IMS core entities. Requirements: Simple to use (collocated with the dev. environment). Deploy SIP applications. Set up network triggers (i.e. iFC, SPTs). Execute SIP applications (composition if necessary). Emulate the IMS service composition and triggering using the SIP Servlet API!

IMS service composition HSS contains the initial Filter Criteria (iFC) for each subscriber S-CSCF: service composition according to the iFC Allow for iFC configuration. Perform service execution and composition according to the iFC.

Servlet object + Application router == S-CSCF SIP Servlet API IMS service development. Emulation implementation. Servlet object -> processing of SIP messages (Route headers). Application router -> application selection. Servlet object + Application router == S-CSCF

Design decisions Applications not tied to a single SIP Servlet Container. Handling special cases (What if the target app. does not exist?). Registration possibility. Persistent triggers (configuration maintained over server restarts). Intuitive user interface. Before going to the implemention, I would like to introduce some of the design choices tha twe made, which motivate the way the IMSCore emulation is implemented.

Implementation CSCF: IMS Application Router: Retrieves the iFC set from the database. Creates the service chain. Adds the Route headers to the SIP request. This is a general overview of the IMS Core emulation architecture. The routing of requests to their target SIP application is made possible through the use of SIP route headers and the custom application router (IMS application router). This allows composition of services (apps) located at any location in the network and not necessarily in the same application server as the emulation (e.g. the service located in the westserver.dtu.dk in the picture). The logic (the IMS, telecom part) of the emulation is contained in two pakages: the CSCF which is a SIP Servlet Object : processes SIP requests, implements the SIP state machine as defined in RFC 3261, acts as a registrar if the feature is enabled for the SIP request, adds the required Route headers such that the SIP requests reaches the intented SIP application. the custom appliction router (IMS AR) which manages the selection of the target application inside a certian SIP servlet container. What was important for us, is that all the software runs and uses the same development environment that it’s used to develop SIP services in the class. So students didn’t have to get accustomed to other tools. As User Agents in the test process we use SIPp. IMS Application Router: Selects the application to be executed.

A short scenario Server1 Server2 IMS AR IMS Core (CSCF) Call Blocking Voice Mail INVITE Route:<sip:callblock@server1;lr> Route:<sip:cscf@server1;lr> Here we have a short scenario based on which I will describe the flow and the actions taken by the functional enities inside the IMS Core emulation platform. I have abstracted the emulation to the two main entities IMS AR and the CSCF Servlet object, because only these two entities really affect the flow of the SIP request. For the sake of demonstration I use two services: Call blocking and Voice Mail. We assume in this scenarion that for this certain request, both applications ust be executed, first the Call Blocking and then the Voice Mail. Describe the flow and the actions performed by the CSCF and the IMS AR. Route:<sip:voicemail@server2;lr> Route:<sip:cscf@server1;lr>

Testing methodology (I) Functional testing. Inspect messages at the end-points and at the application server. By testing we refer to functional testing. We want the students to be able to execute their applications in a realistic environment and be able to infer if the apps are working correctly in a similar way as they would do it with a simplistic testing tool such as SIPp, and that is by inspecting the messages given by the SIP User Agent and the log messages shown by the application server. As am example it’s shown a message log from the UA client indicating that the intended application was not found and the call has been stopped. Message log from the UA client

Testing methodology (II) Here there is a message log taken from the application server during the execution of one of our test scenarios. Message log from the application server

Conclusions Simple yet realistic tesbed for SIP applications. Implementation based on the SIP Servlet API. Requirements: Configure network triggers. Perform IMS-like service composition. Features: Integrated with the development environment. Intuitive work flow. Easy to set up and run. Testing methodology: message log investigation.

Thank you!

Backup 1

Backup 2

Backup 3