Java Jingle

Please note: This page is horribly out of date, it will probably change completely in the next couple of days.

Overview

Jingle provides a framework for initiating and managing peer-to-peer connections between XMPP clients. The implementation of Jingle in Java is a Google Summer of Code 2006 project being executed by Alasdair North and mentored by Matt Tucker. The focus of the project is on client side functionality and aims to produce the following:

• Java Jingle library.

• Classes to implement audio streaming.

• Documentation enabling client designers to easily make use of the library.

• A small number of example programs.

Initial Design Ideas

I'm currently revising for my finals, so design work is going pretty slowly at the moment. I thought it would be a good idea to get down some of my thoughts on the design structure of Java Jingle. I'm not an experienced XMPP programmer so I may well be making false asumptions about how things work. If you do spot anything that looks odd then please do email me or put something on the talk page.

Jingle is quite a flexible system. It can be used to set up communications using a number of different media formats over several different types of link. By the end of the project I hope to have a small number of audio formats working over one or two transport types. However, I intend to make it as easy as possible for other programmers to add in new classes that support other transport and media types.

The first step in designing Java Jingle will be define the interfaces that must be implemented for each of the following four types of classes.

Session Negotiation - The process of setting up a Jingle session will differ depending on how XMPP connections are dealt with in the client. Classes that implement the session negotiation interface will deal with XMPP connections in the context of the client application and make it possible for a Jingle connection to be started. It may turn out to be more practical to have two interfaces here, with one dealing with listening for new connection requests.

Transport - Once a session has been negotiated it is managed by an object implementing the transport interface. This looks after the task of sending the bits to the transport object at the other end.

Media Engine - Classes implementing this interface will take care of encoding and decoding the data that is to be sent. This could be audio data, video data, or marshalling files for transfer. It may make more sense to have two interfaces here, one for encoding and the other for decoding.

Hardware Interface - These classes interface with the user's hardware (microphone, speakers, file system, etc) and deal with the input and output of the raw data.

The Java Jingle stack

At runtime the transport and media engine objects will be provided by factory classes. In addition to instantiating new instances of the classes they will be able to give the session negotiation classes data on what media and transport types are supported by this particular system.

Current Progress

Week One (22 - 28 May)

Most of my time has been taken up with revision for my finals (I think this is the hardest I've ever worked in my life!), but I have been able to spend sometime researching Java Jingle.

I've spent some time reading through the relevant XEPs and familiarising myself with the Jingle protocol.

I've also been thinking about the overall design of the library and how it will negotiate a Jingle session and interface with the Jingle client software. The session negotiation has been a particular focus, as it turns out it may be a bit more complex than I first thought.

Week Two (29 May - 4 June)

Wrote a few prototypes to explore how XMPP works. Investigated RTP libraries.

Week Three (5 - 11 June)

No work done due to exams.

Week Four and Five (12 - 25 June)

I was always a bit cautious as to how much I'd actually be able to get done in this period, as I haven't had much time to contribute to the project. I haven't managed to get much done. I have been working on using the JMF to set up RTP sessions between machines. I've also been coordinating with Alvaro Saurin who's doing a similar project for Adium. We're colaborating on an extention to the Smack library enabling Jingle signaling. He's done quite a bit of coding so far and I'm looking forward to getting my teeth stuck in.

Rough Schedule

The first few weeks of design will be slowed significantly by my finals. After week three I will be spending the time I can on the project.

Week One (22 - 28 May)

Think through overall design. Investigate libraries for session negotiation, media coding and transport.

Week Two (29 May - 4 June)

Build a small number of prototype programs for XMPP communication (using Smack) and audio streaming over RTP (using JMF).

Week Three (5 - 11 June)

ARGH!!! Exams! If time, play around with more prototypes.

Week Four (12 - 18 June)

Finalise design. Create detailed description of interfaces and expected behaviour. Write stub classes.

Week Five (19 - 25 June)

Create a small number of programs to test library functionality. This includes hardware interface classes.

Week Six (26 June - 2 July)

Write classes to negotiate a Jingle session using the Smack library. Make a start on a class implementing RTP-ICE.

Week Seven (3 - 9 July)

Finish the RTP class. Write media engine classes for at least one audio encoding (whichever is the easiest codec to use).

Week Eight (10 - 16 July)

Write classes to support more media encodings and transport types.

Week Nine (17 - 23 July)

Spend one more day on media encodings and transports. Give the rest of the week over to documentation and creating examples.

Week Ten (24 - 30 July)

Contingency time. If it's all gone well so far then look at file transfer over Jingle and code a media engine to deal with this. This will hopefully use the XEP defined as a result of the Psi JFT SoC project.

Week Eleven (31 July - 6 August)

Contingency time. If all well at this point then consider integrating Java Jingle into an existing client (perhaps Spark). I probably wouldn't be able to finish this in the summer, but I will carry on after August.

Week Twelve (7 - 13 August)

Contingency time. Continue possible client integration.

Week Thirteen (14 - 20 August)

Contingency time. Continue possible client integration. Write up any reports and documentation needed for the end of the Summer of Code.

Relevant XEPs

• XEP-0166: Jingle
• XEP-0167 XEP-0167: Jingle RTP Sessions
• XEP-0176 XEP-0176: Jingle ICE-UDP Transport Method
• XEP-0177 XEP-0177: Jingle Raw UDP Transport Method