This is a short notice of two new projects I am initiating and inviting members to be involved with.

Jitsi-Jingle

There has been an outstanding request to bring the Jingle implementation of Spark/Openfire up-to-date and compatible with newer implementations from NimBuzz, Gtalk and Jitsi. Openfire has a Jingle-Nodes plugin which replaces the legacy Openfire media proxy, but it is ignored by Spark.

The ideal and proper way of doing this would be to update the Smack Jingle library (smackx-jingle), but it seems to be abandoned and would require some effort to study the code and appreciable time to implement the changes. The other option is to hack a working and actively maintained implementation based on Smack like Jitsi. As I have an immediate need for a Java-based Jingle library, I have opted for the second option.

The project is hosted here. If you are interested and can afford to be involved, please send me a private message

Openfire-Ringo

Once upon a time I used to code server-side JavaScript in the Netscape and IIS and all that changed with managed code, frameworks and templating using J2EE or .Net. As usual, life goes on in repeating cycles and JavaScript is now the rage and back in fashion thanks to NodeJs and Google's very fast V8 JavaScript engine. I recently caught up with RingoJs which is a ComonJs framework implementation of Mozilla'a Rhino JavaScript engine. Rhino imay not be as fast as NodeJs, but because it uses Jetty 7.5, it will enables us to provide Openfire with its own server-side scripting engine.

So what can we do with Openfire-Ringo?

Quite a lot. Just imagine JavaScript plugins for Openfire that can be managed directly from the admin web console and having privilege access to the Openfire server-side API and plugins. They can be used to extend Openfire like regular Java plugins and expose the business and enterprise features of an XMPP server like Openfire to a new generation of jQuery developers.

The project is hosted here. If you are interested and can afford to be involved, please send me a private message

Update

Got first working version of OpenfireJS running. I am quite please with the results.

Here is a working example of using Openfire Message Interceptor to intecept every message in Openfire and print the packet to the info log file from JavaScript. The script will continue to run until Openfire is shutdown or the script is deleted.

var log = Packages.org.jivesoftware.util.Log;

var interceptorMgr = Packages.org.jivesoftware.openfire.interceptor.InterceptorManager;

var interceptor =  { interceptPacket: function (packet, session, incoming, processed)

{

          if (processed) log.info(packet);

} }

var myInterceptor = new org.jivesoftware.openfire.interceptor.PacketInterceptor(interceptor);

interceptorMgr.getInstance().addInterceptor(myInterceptor);

To give it a spin, head to the project home page. You will need Openfire 3.7.2 with jetty 7.5.  Not tested on on any lower version

Jingle [1] defines a framework for negotiating and managing out-of-band multimedia sessions over XMPP. In order to provide a flexible framework, the base Jingle specification omits data transport methods and media session types, requiring separate specifications. Typical peer-to-peer session types include voice chat (see Jingle Audio Content Description Format [2]) and video chat (see Jingle Video Content Description Format [3]) which are based on the Real-time Transport Protocol (RTP) and will be suitable for WebRTC.

WebRTC uses a protocol called JavaScript Session Establishment Protocol (JSEP) [4] that pulls the media negotiation and signaling state machine out of the browser into JavaScript. JSEP like Jingle separates session descriptions from transports and exposes the media negotiation to the application developer making it very compatible with Jingle,.

In order to use WebRTC with the Jingle RTP-ICE Transport Method [5] requires the developer to translate between the web browser session descriptions and Jingle. This means understanding WebRTC SDP and correct translation into Jingle by the call initiator and back into SDP by the call target. The developer must also create correct RTP-ICE transport candidates at both call ends.

When both paticipants of an audio/video call are both web browsers supporting WebRTC,  we already know that the web browsers will transport the media between each other, so it makes for a simpler and neater approach to simply forward the session description messages emitted from the web browser as Jingle session info payload messages instead of translating web browser SDP offer/answer media data into Jingle session descriptions and constructing redundant transport candidates.

This document defines a new Jingle transport method for establishing and managing WebRTC media streams.

For the full proposed specification, please go here