1. Page  1 Developing a Cross Platform IMS Client using the JAIN SIP Applet Phone Muswera Walter Supervisor: Prof Alfredo Terzoli

2. Page  2 Introduction  There has been a growing interest in the adoption of the IP Multimedia Subsystem (IMS) by industry and research institutes.  This has resulted in the establishment of IMS testbeds for developing and deploying IMS services.  Client applications used for testing and consuming services within these testbeds are important for the overall success of the developed services.  Client applications available today often support a limited set of basic services

3. Page  3 Convergence Research Group (CRG) Testbed

4. Page  4 Problem Statement  Several free open and closed source clients are currently being used by the CRG developers such as: –IMS Communicator –UCT IMS Client –Mercuro  No single client is available that has all the required features to test the applications being developed.  Most clients: – can only be used on specific platforms – support a limited range of video and audio codecs  Testing becomes difficult since developers have to find workarounds.

5. Page  5 Main Objective  Provide a unified client for application testing to researchers in the CRG that is: –flexible and easy to extend –cross-platform for easy deployment –IMS and SIP compliant

6. Page  6 JAIN SIP Applet Phone (JSAP)  JSAP is an open source project which is currently being managed by one of the CRG team members.  It has a mature code base and possesses some of the features required for application testing such as: –voice –text Instant Messaging (IM)  JSAP supports basic SIP signaling using the JAIN SIP API: –registration –session setup  It uses JMF as its media API.

7. Page  7 JSAP Limitations  JSAP only supports ordinary SIP signaling and session setup.  Video implementation in the JSAP is not fully functional: –live video capture is a problem in with JMF Linux –JMF lacks support of some of the new major codecs.  Presence in JSAP is implemented in a peer to peer manner.  Lacks support for XCAP.

8. Page  8 Sub Goals  Modify JSAP to support the core IMS functionality: –IMS registration –IMS session setup  Preserve current SIP support in JSAP: –IMS functionality is built on top of ordinary SIP functionality  Complete replacement of the media API used in JSAP: –problems with JMF

9. Page  9 Implementation  Extensive assessment of the JSAP was carried out before replacement of the media library and addition IMS support could be done.  The assessment involved carrying out systematic experiments such as: –tracing of messages sent by JSAP using network analysis tools to check their sequencing and well formedness –reverse engineering to find out the relationship among the various classes –discussing with some of the original developers of JSAP.  Having gone through the aforementioned processes a structure of JSAP was drawn up.

10. Page  10 Implementation - Derived JSAP Architecture

11. Page  11 Implementation – Integration of IMS Registration  JSAP only supports ordinary SIP registration.  IMS specific headers needed to be added on top of SIP headers to make the client IMS compatible.  In summary the process involved: –identifying the classes which needed to be modified to add IMS support – adding helper classes for populating IMS specific parameters –optimising or replacing some existing classes with ones that allow the support of IMS –adding XML support to allow the populating of IMS/SIP attributes and to allow persistence

12. Page  12 IMS Registration

13. Page  13 Implementation - Integration of IMS Session Setup  JSAP only supports basic SIP session setup.  Tested the client for interoperability with other SIP and IMS clients: –Twinkle –Mercuro  Test scenarios were based on end to end system testing: –higher level functionality rather than specific protocol requirements

14. Page  14 SIP Session Setup

15. Page  15 IMS Session Setup

16. Page  16 Implementation  Bugs that have been identified in the JSAP have been cleaned: –unhandled server responses –client requests user credentials when re-registration has expired –replacement of deprecated methods  Duration for which user registration credentials are valid.  XML support for loading and storing IMS/SIP parameters –persistence of user configurations –will also be used to keep a list of supported codecs

17. Page  17 Registration Interfaces

18. Page  18 Call Interface

19. Page  19 Current Work – Integration of gstreamer-java media API  An investigation of alternative open source media APIs to the JMF was carried out  Among the projects investigated were a variety of implementations building on top of JMF such as FMJ  Gstreamer-java was chosen due to the following factors: –it supports most major codecs –it is still under active development –these java bindings are portable across operating systems  Testing functionality of new media API