S60 SIP Application Development Process
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 networkas 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 gameswhich 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 SDPwhereas 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.
A Web 2.0 Experience
|Figure 5. The MBit Network: An S60 SIP-based Web 2.0 application.|
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.