End-to-end IMS Application Development with Nokia Siemens Networks IDP Development Tools

by Dennis Luemkemann and Manfred Jakesch
03/05/2008

Abstract

In this article we show how to develop and test an IP Multimedia Subsystem (IMS) application with both a client and a server part, using the free standards-based development tools from the Nokia Siemens Networks IMS Developer Program and BEA WebLogic SIP Server (WLSS). The IMS is a complex environment but with the right tools, that complexity becomes manageable, and end-to-end tests can be made even on a single PC.

Converging Networks and the IP Multimedia Subsystem (IMS)

Telecommunications providers are looking for ways to offer more services to their subscribers than the traditional voice and short message/multimedia message service. They are adopting established technologies from the IT world, such as the Internet Protocol (IP), the Session Initiation Protocol (SIP), application servers, and streaming media. This makes the formerly proprietary and closed environment of telecommunications open to IT developers who are looking for new markets and opportunities. For more about SIP, have a look at the article An Introduction to SIP, Part 1 (Dev2Dev, 2006)

Standardization groups such as the Third Generation Partnership Project (3GPP) have specified the IMS as a generic platform for services which provides an advanced infrastructure for applications. Telecommunications providers around the globe are deploying this system, which plays a key role in the convergence of formerly separate networks like the public switched telephone network (PSTN), cable television networks, and the public Internet. In this converged world, an application doesn't just run on one PC or the Internet, but it is accessible from wherever you are and whatever device you are using.

To deliver on that promise, the IMS must have the ability to convert between many types of media formats, transport protocols, and signaling protocols, and it must provide a mechanism for routing traffic from one user or network component to another. While the IMS takes care of all this, the developer can concentrate on the actual application.

Figure 1 shows the main components of the IMS. The Call Session Control Function (CSCF), shown with its three roles for proxying (P), interrogating (I), and serving (S), acts as a SIP proxy and takes care of authentication together with the Home Subscriber Server (HSS), which stores the subscriber profiles. A presence server (Mobile Presence Manager, or MPM) keeps track of users' presence state and sends notifications when these states change. In combination with a group list management server (Community Services Data Manager, or CSDM), it provides the network backend for buddy lists in applications. The IMS Network Emulator emulates these components. SIP application servers can be attached to the CSCF, and media and signaling gateways translate between different access networks and devices.

Development Tools from Nokia Siemens Networks

The IMS Developer Program (IDP) helps developers write applications for the IMS and bring them to market. A lot of tools for mobile application development are already available and established, so the IDP focuses on tools related purely to IMS and SIP, letting developers set up an environment with their favorite tools and emulators and on their favorite operating system, to develop IMS applications.

For this article, we used the IMS Network Emulator and the Java ME IMS SDK for the client. Besides this SDK for Java-enabled mobile phones, there is also a .NET IMS client SDK for Windows and Windows Mobile. All these tools can be downloaded for free at the IMS Developer Program Web site.

Let's look at these tools in a little more detail:

IMS Network Emulator

This tool represents the infrastructure side, the IP Multimedia Subsystem, and emulates the real IMS with its main components: the CSCF (Call Session Control Function, a SIP proxy) and the HSS (Home Subscriber Server, basically a user database and SIP registrar). Besides these core IMS functions, the Network Emulator also emulates an OMA presence server and an XML Data Management server, two components that are typically available in an IMS installation to provide system-wide presence information to any subscriber or application that needs it.

The IMS Network Emulator is a stand-alone Java application, which can be run on either your development PC or a separate machine. It has a graphical user interface for configuration and local setups and a Web interface for remote setups.

Java ME IMS SDK

Most mobile phones currently on the market do not support the SIP protocol, not to mention IMS services such as presence. While it is theoretically possible to implement your own SIP protocol stack or use one of the existing SIP stacks, you would end up spending a significant amount of your time reading specs and writing code for setting headers, calculating authentication information, and so on. Wouldn't it be nicer to have a high-level API that lets you use SIP services with just a few lines of code? This is where JSR 281 comes in, the IMS Services API. It makes using SIP and integrating IMS services into your applications easy.

The Java ME IMS SDK is a library for Java ME devices (usually mobile phones) that contains high-level APIs for SIP and IMS services. It uses the JSR 281 draft specification. There are two version of the library: one is for general MIDP 2.0 / CLDC 1.1 devices and includes a SIP stack; the other one is for Nokia S60 3rd Edition phones, which have a built-in SIP stack with JSR 180 API. See the article Introduction to the SIP API for Java ME (Dev2Dev, 2007) for more on JSR 180.

PictureQuiz Application

An easy way to appreciate the IMS architecture is by examining and using a demonstration application. The PictureQuiz is a simple example application that illustrates the important aspects of IMS client and server application development. It is available with source code from the IDP developer portal. This section provides an overview of the application, its architecture, and client/server calls.

Overview

The quiz game consists of a server application that sends questions to quiz clients. For each question, three possible answers (A, B, and C) are proposed, and each quiz player has a limited time in which to select an answer. Because pictures are used in questions next to the text, you can have questions like "Name this president" or "Which flower is this?."

A game round is closed when either all clients respond to the question, or a timer expires at the server. At the end of each round, the correct answer and the winner from that round are sent to all quiz players.

Architecture

The application consists of three main components, as illustrated in Figure 2:

1. The SIP application server (SIP AS) runs the game logic, holds the questions repository, and serves the pictures.
2. The IMS is the infrastructure provider for the application. This application uses the CSCF (mainly the Proxy and Serving role) through the Gm (client/SIP) and ISC (application server/SIP) interfaces. Therefore, the IMS Network Emulator can be used for running this application.
3. Finally, the clients provide the interface to the user, display the questions and possible answers, and send the user's choice back to the server.

The server

The server application implementation is based on the standardized JSR 116 SIP Servlet API. Therefore, it can be deployed on any SIP application server that implements this standard. The current version has been tested on BEA WLSS 3. For more information on programming SIP servlets, see The SIP Servlet Programming Model (Dev2Dev, 2007).

Subsequent to a successful registration with the IMS, the player will be automatically registered at the quiz server. The server recognizes a player on the basis of the SIP third-party register message that is sent to the server from the S-CSCF. This registration process is used to ensure that a player is allowed to access the quiz game.

Once a player is ready to play the game, the client application initiates a session using a SIP INVITE message. The user is then considered by the server to be ready to play, and will receive questions with each new round of the game. All clients receive the same question and compete with each other to answer each question.

Once the winner of the current round has been determined, a message will be sent to all registered clients announcing the winner and the correct answer. If no winner is determined, this will also be communicated. After this, the server sends the next question.

The call flow illustrated in Figure 3 shows the standard use case for the SIP interface of this application. To simplify the illustration, only the main component of the IMS (CSCF) that is used by the application is displayed.

The source code to the server application is included in the PictureQuiz package. If you use Eclipse and WebLogic SIP Server, you can use the WebLogic Server Tools to compile and deploy the application. Alternatively, you can use the Ant build file to compile and to deploy the servlets with a dedicated task for WLSS.

The PictureQuiz server is a converged application, where SIP protocol functionality is combined with HTTP functionality. The server has a Web interface for configuring the application and to start a game from the server. You can choose from the currently registered/online users and invite them to play.

The client

A client could be written for any (SIP-capable) platform, since all it has to do is communicate with the server using SIP and HTTP and display questions and results. In this article, we use a Java ME client, built with the Java ME IMS SDK with JSR 281 API (see Figure 4). If you prefer Windows or Windows Mobile, you can also download and install the Win.NET IMS SDK, which contains a PictureQuiz client (including source code) for these platforms.

If you already have an existing setup for developing MIDlets with IDE and device emulator, all you have to do is copy the library JAR file to your project and include it in the classpath and project exports. This gives you access to the necessary IMS functions. If you haven't developed any MIDlets before, read the great articles on Java ME from Sun to get started.

Generally, the data exchanged during a SIP session is a "media" of some sort. It can be an RTP stream, an MSRP transfer, or anything that suits the application. The PictureQuiz simply uses SIP MESSAGEs sent within the game session. The media used is described during the session setup. In JSR 281, there is an API to establish a session and a mechanism to implement custom media types. We need to implement such a custom media for the PictureQuiz and add it to our session.

One nice feature of the PictureQuiz application is the application wake-up. When deployed on a phone with built-in JSR 180, the device's Push Registry mechanism can be used to launch the PictureQuiz MIDlet when a SIP INVITE for the PictureQuiz is received. This goes hand-in-hand with the server's Web-based game start option.

End-to-End Testing in an Emulated Environment

Before running the application, you have to make sure to correctly configure the IMS Network Emulator. If you are using the standard configuration with default users, this means adapting the initial filter criteria or triggers of those default users. This mechanism is a feature of the CSCF, where SIP messages that match some predefined criteria can be forwarded to SIP application servers. Two trigger entries are necessary: one to catch the REGISTER request so that the server knows which users are online, and the other to receive the INVITE request to start a game.

For an end-to-end test, ensure that the IMS Network Emulator is started and running and the WLSS is running with the PictureQuiz application deployed. To start the WLSS from your Eclipse IDE, you can use the WebLogic Server tools mentioned above.

Check that the application is correctly deployed by entering the address http://<address_of_wlss>:7001/quiz in your browser. It should display the main Web page of the application.

If everything looks ok, open the Trace Viewer of the IMS Network Emulator to see the SIP traffic. Start your client in its emulator or on a real device using WLAN. The client should show up as registered in the IMS Network Emulator and on the application's Web page. Now you are ready to begin the game. In the Trace Viewer you can see the session invitation and the exchange of messages between client and server.

Summary

With this example application, we have shown how easy it is to develop an application for the IP Multimedia Subsystem. The additional complexity of the IMS is encapsulated in the IMS Network Emulator, and the additional functions of IMS become accessible through the JCP standard APIs JSR 116 for the server side and JSR 281 for the Java ME on the client side.

The free tools from the IMS Developer Program integrate seamlessly with other tools for client and server development and allow for single machine or distributed test environments.

References

• Nokia Siemens Networks IMS Developer Program - free IMS tools, documentation, and discussion forum
• JSR 281 - IMS Services API
• JSR 116 - SIP Servlet API
• JSR 180 - SIP API for J2ME

Dennis Luemkemann is responsible for the framework and development tools at the Nokia Siemens Networks IMS Developer Program.