hinking about developing multiplayer interactive games, multimedia messengers, content-sharing applications, audio/video conferencing applications, or maybe the next cool Web 2.0 application on a smartphone? You might want to consider developing for Nokia’s S60 smartphones and take advantage of the platform’s extensible features and SIP support.

The S60 platform is now in its third edition, bringing SIP support in both IETF and 3GPP modes. IETF SIP support was available on some S60 second edition devices.

SIP Defined
Session Initiation Protocol (SIP) is essentially a text-based request response protocol similar to HTTP used for creating, modifying, and terminating peer-to-peer (P2P) sessions. It is specified in RFC 3261 and has been extended by 3GPP to support the requirements of cellular networks. In a cellular environment?2G, 2.5G, 3G, 3.5G?it is used to communicate with the operators’ IMS (IP Multimedia Subsystem) networks and in a Wi-fi environment it could be used to connect to SIP-based application servers on the Internet. The basic SIP server-side elements allow different kinds of SIP-enabled devices to establish direct connections with each other, bringing about convergence and opening new opportunities for S60 developers.

Figure 1. Overview: The Simplied IMS/SIP Network.

P2P connections cannot be established in most cellular networks without IMS and usually require the development of proprietary session handling protocols and servers. With support for SIP on S60 and IMS in operator networks, it is now possible to have applications communicate in a P2P fashion– even when roaming from one operator network to another. SIP helps reduce the time-to-market of multi-user applications and greatly improves the user experience for such applications.

Figure 1 shows a simplified IMS/SIP network that S60 smartphones use in order to establish a SIP session in a GSM or Wi-fi environment. A registered SIP application is “reachable” by other SIP applications on the network. Its first contact point into the SIP/IMS network is the SIP proxy server or equivalent through which all SIP requests pass. The Registrar server provides the service to store the mapping between the SIP username and the IP address of the device with which it registers. The SIP Proxy and Registrar servers are configured on an S60 device in an SIP profile.

The kinds of services an IMS network could provide are varied: presence, group management, push-to-talk-over cellular (PoC), gaming services?but these specific services depend on applications servers’ integration to the IMS network. However, it is possible for third parties to develop their own services by using standard SIP Servlet APIs or third-party SIP application server environments like Ubiquity.

Using SIP on S60
Figure 2 shows how S60 3rd Edition supports both Java (JSR 180) and C++ APIs for SIP development. The development processes for developing C++ and Java-based SIP applications are shown in Figure 3 and Figure 4, respectively. The SIP C++ development process differs slightly between early S60 2nd Edition devices and later 2nd Edition devices and also faces source and binary compatibility breaks on S60 3rd Edition devices.

Figure 2. SIP on S60: S60 3rd Edition supports both Java and C++ APIs.

A typical SIP implementation separates the user interface and engine, like most S60 native applications, but usually splits the engine further into two sub-engines?one for SIP-based negotiation and event handling, and the other for application-specific data communication. The SIP engine you build has to be tailored to your needs. For example, if you are developing a VOIP, multimedia sharing, or PoC application, you should implement the Offer Answer model as specified in RFC 3264, and use S60’s transaction level SIP APIs. Development of a typical SIP application on S60 would require:

• Basic SIP protocol knowledge
• Complementing of pre-initialized SIP messages provided by the API with service-specific headers and content
• Encoding and decoding of message bodies, for instance the SDP content body describes application identity, port, protocol, and media codec support.
• Management of negotiated media channels, for instance, the establishment and teardown of specific UDP/TCP connections
• Management of event subscriptions and instant messages, for example, creating and parsing SUBSCRIBE, NOTIFY, and MESSAGE messages.

S60 SIP Application Behavior
SIP applications on S60 can be triggered to start by an incoming SIP message. As all SIP messages are received on the same port on S60 device, the platform provides the framework for client resolution. C++ developers need to develop a client resolution plug-in, whereas Java developers use the Push Registry to register (statically or dynamically) the content type the application is willing to accept. The Accept-Contact header must be sent in the SIP request for client resolution in Java SIP applications, whereas, on for native SIP applications, it is recommended but not there are also few other options:

• Message content type
• Application identity, media type, and codec support for RTP (real-time transport protocol) described by SDP (session-description protocol)
• SIP’s SUBSCRIBE message’s Event header
• Accept-Contact Header

Both C++ and Java applications usually use SIP profiles, which provide the necessary settings to register with IMS or SIP networks, as well as define some SIP stack-related behavior. One SIP Profile can be used by different SIP applications or each application can have its own. The SIP Profile can only be provisioned over the air on S60 devices with Nokia VoIP 2.0 and has to be entered manually on others. The information in the profile usually consists of the following:

• Service Profile, IETF or 3GPP (IMS) Mode: This does not really impact the developer as the APIs are mode agnostic. The SIP stack takes care of the mode specific authentication during the registration process, addition of 3GPP related headers and such. Developers are recommended to simply ‘enable’ the SIP profile through their C++ or Java code.
• Access Point: This is used for SIP communication and the same could be used for the application data communication channel, usually established after the SIP INVITE handshake. The Access Point could be GPRS, 3G, or Wifi-based, depending on the support on the device.
• SIP User Name: This is the SIP identity used by remote SIP applications to communicate with the application’s associated with the profile.
• Compression Mode: Set at On/Off, this is used to compress SIP messages.
• Registration mode: Set at When needed/Always On. If set to Always On, then the profile registers upon phone boot up and the associated applications can be reached even when they are not running.
• Security Mode: Set to On/Off. If security is on, then the registrar server must support Sec-Agree specified in RFC 3329.
• Proxy Server and Registrar Server: These settings usually point to the same server and if unknown, could be set to 0.0.0.0, so that the SIP stack can do a DHCP based look up.

S60 SIP Application Development Process
Figure 3 shows the development steps for a S60 C++ SIP application.

• Carbide.c++ comes in different versions and usually the third party developers need the professional version to be able to make use of the tool for rapid UI development and for on-device debugging. S60 SDKs plugin to the Eclipse-based Carbide.c++ IDE. The SDK provides the emulator where the SIP Profile needs to be setup.
• Implementing a SIP application in C++ is just like implementing other native C++ applications on S60. It requires SIP-related headers and libraries as well as the implementation of an Client Resolver Ecom plugin to enable SIP stack to forward an incoming SIP essage to the right SIP application. There is a DTD in the SDK that describes the critieria that can be used for resolution.
• The last two steps are common for any native S60 application, except it is important to note that the SIP API on S60 3rd Edition requires capabilities which can only be granted via Symbian Signing and not simply through self signed certificates. The S60 3rd edition’s security framework requires that you make use of these capabilities.

In order to test a SIP application against the SIP server emulator, you will have to install the environment on 2 PCs. This is because it is currently only possible for one S60 emulator and one SIP server emulator to communicate with each other on a PC. You need to change the default port (5060) that the SIP server emulator uses because the current S60 emulator also uses port 5060 for SIP communication. You can also use a real SIP server on your network?as long as you configure the emulator’s SIP profile for it.

Figure 3. The S60 SIP Development Process: The image shows the S60 SIP development process in C++.

Figure 4. The S60 SIP Development Process: The image shows the S60 SIP development process in Java.

Figure 4 shows the SIP development process using Java on S60.

• Carbide.j is a plugin to the Eclipse IDE that is used to package and sign a MIDlet as well as manage the various MIDP SDKs. S60 3rd Edition MIDP SDK uses the same S60 and SIP emulators as earlier but integrates into Eclipse and Carbide.j.
• The Java-based SIP application is developed like other MIDP applications and usually makes use of the Push Registry so that the MIDlet can be started by an incoming SIP message with a unique Accept-Contact header.
• The last two steps are common to any kind of MIDlet development.

You can use the S60 emulator and SIP server emulator to test Java SIP applications in a similar way as described earlier. MIDP Java applications are not affected by the S60 3rd Edition’s security framework.

When Should You Use SIP on S60?
Currently, third parties should concentrate on using SIP APIs for applications that simply need to establish peer-to-peer sessions, but not implement complicated multimedia sessions. IETF SIP signaling could be enough for most non-multimedia applications, even in an IMS environment. Extended SIP features like those for messaging, event publishing, subscription, and notification are supported and could be used to provide features like game lobbies in multiplayer games?which operators usually request. The SIP extension methods MESSAGE, PUBLISH, SUBSCRIBE, NOTIFY, REFER, and PRACK are all supported on S60 3rd Edition.

Should You Use the Java or C++ SIP API?
To answer this question, it’s helpful to analyze the non-SIP related requirements of your application. The C++ API provides more flexibility with client resolution as well as supporting an API to encode and decode SDP?whereas the Java API does not. Java SIP API is good for multiplayer Java games, which have been limited to SMS for peer-to-peer interactions and have required proprietary game servers for real-time gaming. However, the S60 C++ API side provides deeper access to S60’s multimedia features through full-duplex access, direct screen access and better interaction with S60 platform core applications available on all S60 devices.

Before you start developing your SIP applications, do give some thought to the possible charging models, as these can affect the SIP messaging you will use. Charging in an IMS environment can be:

• Time-based: Charges are based on the length of time a user consumes various types of media during a multimedia session.
• Transaction-based: Charges per SIP MESSAGE request
• Payload based: Charges are based on the content type and size of a SIP message.
• Subscription-based: Charge is a monthly fee for a presence and gaming service.

Figure 5. The MBit Network: An S60 SIP-based Web 2.0 application.

A Web 2.0 Experience
Figure 5 shows screenshots of an S60 SIP-based Web 2.0 application developed by a Forum Nokia PRO member company, N2N Consulting, using the S60 C++ SIP features.

The application, called MBit Network, is a peer-to-peer network for S60 smartphones that allows sharing, searching and downloading mobile content, as well as chatting with buddies who share the content on their S60 smartphones.

The SIP protocol for allows these types of applications to manage the sessions associated with each of the features mentioned above. Groups allow the users to share and search within a group of SIP users. Features such as group management and presence should ideally be provided by SIP-based application servers in the operator’s IMS environment, but they could be developed by third parties as well, if they require servers anyway for managing other tasks.