Skip navigation
All Places > Ignite Realtime Blog > Author: Dele Olajide

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


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



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



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 =;

var interceptorMgr =;

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


          if (processed);

} }


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



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

I have a just added WebRTC audio/video support to OfChat to confirm that the proposed WebRTC transport for Jingle actually works.



OfChat is a web client for Openfire implemented as a Chrome extension. I am not releasing the WebRTC code until the the next release of Chrome which will use JSEP instead of ROAP.




I have attached the latest OfChat Chrome extension (ver 0.0.8) with support for WebRTC using the Jingle WebRTC Transport proposal. Sadly, the proposal is to be withdrawn, so this might be incompatible with anything else in a few months time. See posting below for requirements. It is all in HTML and JavaScript, so finds where Chrome installs it to see source code.

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

For those who are following, WebRTC is a free, open project that enables web browsers with Real-Time Communications (RTC) capabilities via simple Javascript APIs and is now available for Chrome.


A while ago, I implemented a Websocket plugin for Openfire that uses Jetty 7.5. Work is already under way by community member Pat Santora to make it a core plugin for Openfire.


WebRTC with WebSockets when fully functional, will enable audio and video conferencing from a web browser without the need for a browser plugin like Flash and even a media server like Red5. The media connection will be peer to peer directly between browsers and the signaling can be SIP, Jingle or whatever over a WebSocket connection or HTTPRequest.


To see how WebRTC compares to Flash Player with RTMFP, I created a simple web page demo using the WebSockets plugin for Openfire and JavaScript and tested with the latest Chrome Canary 19.0.1041.




Performance is good, but it is still early days as the WebRTC specification is still evolving. There are active debates on signaling, device capability discovery and where to hide the the complex code; JavaScript libraries or the Browser. For those who want to see what's under the hood, I have attached the single web page. Run two instances from two different PCs. Change the JavaScript to suit your own Openfire server.


I think I have enough to get started on adding two-way Jingle Audio/Video to the OfChat web client using a WebRTC compatible transport.

If you use openfire-jappix plugin on your server, you should update to version 0.0.2 which uses the the new 0.8 package


Please read



Ignite Realtime community is happy to release OfChat (Openfire Chat), a Google Chrome extension that puts a chat toolbar on any web site you want so you don't have to switch back and forth between tabs or have to resize your browser window to include your desktop chat application on your screen.




OfChat does not require a front-end Apache web server or middle-man BOSH server and connects directly with Openfire eliminating the cross-domain issues associated with web browser application like SparkWeb, Jappix or Candy. With WebSockets, it is as fast as a chat desktop application. It also uses Google Alerts when the Chrome window is minimised.


OfChat is based on on Gtalklet for by Sean Zheng and has been modified to work with Openfire BOSH and the WebSockets Plugin for Openfire 3.7.1. It uses Strophe JavaScript library by Jack Moffitt and includes a new Openfire.Connection class which implements the full Strophe.Connection class for Openfire WebSockets. Openfire.Connection should work with other Stophe based applications as a direct replacement for Strophe.Connection..


OfChat does not have a conventional roster display with groups. You have to start typing into the search area to filter a list of contacts in Google search style and like the new Facebook contact list view. In order to see only online contacts, just press spacebar as your first character. Support for MUC (group-chat) has been added, but you will need the Openfire client management plugin to create user group chat bookmarks.


Support for WebRTC audio and video has also been added.


To install from Chrome, just click on this link.


After you install the extension, go to the extension's preferences and enter your Openfire account credentials. Enter your Openfire BOSH URL. It is usually http://your_server:7070/http-bind/. Please don't select WebSockets unless you have upgraded your Openfire server to use jetty 7.5.1+ and running the WebSockets plugin. Once you've signed in, reload one of your tabs and you should see it pop up in the lower right-hand corner. Once you see it in the corner of your screen, just hit the grey circle to log in. Once you log in, you can set status as normal. Click the plus sign as many times you need to search for a contact and start a new chat.You can block it from showing up on certain sites from the extension's preferences.

This is an implementation of WebSockets for the Openfire XMPP server. It consists a plugin for Openfire and a low-level JavaScript library suitable to be used with jQuery.



Recently, I have been involved in shaping an XMPP protocol extension (XEP) for simple application remote control of telephony devices for financial trading systems. This XEP is called Openlink and is still evolving.


I use XMPP Bosh to provide an Openlink Javascript library for web based applications and I am seeking to improve performance and scalability beyond the limitations of long-polling BOSH connections, so I decided to investigate replacing BOSH with Websockets in my Openlink Javascript library.

What did you do?

The Websocket protocol is close to finalising and Jetty (the embedded web server for Openfire) has been supporting WebSocket since Nov 2009 in version 7.0.1 which is the Jetty version in current Openfire 3.7.0. My first attempt of using the Jetty WebSocketServelet? class from Openfire 3.7.0 with Google Chrome web browser failed and I am not sure why. The WebSockets specification has changed a lot over the last two years and both Chrome and Jetty have kept up with it, so I was not surprised.


I therefore decided to recompile Openfire from SVN (version 3.7.1 Alpha) with latest Jetty 7.5.1 and finally got it working.



I then implemented a very thin XMPP stanza based Javascript class called openfire-websockets which exposes a minimium "Stophe" like connection object which I tested with the XMPP console application in chapter 4 of the book "Professional XMPP Programming with JavaScript and jQuery" by Jack Moffitt.





You can use this plugin from Openfire 3.7.0. Just replace openfire.jar and slf4j-log4j12.jar in OPENFIRE_HOME\lib.

Should I?

If you do most of your application development with XMPP like I do, using Openfire and need fast and simple access to the low level XMPP messages as DOM elements in Javascript from JQuery right now, then take a look at openfire-websockets.js





I have received a couple of emails about Jappix MiniChat not working properly with Openfire BOSH.  The main issue seems to be that the Openfire BOSH is not handling the reconnection properly as the user browses from page to page.


I'll be surprised if it did as the implementation was a few years ago and the BOSH specification has moved on since. More importantly was that it was designed to work with SparkWeb which was always resident on the web page until the user logged off. In this mode, Openfire BOSH works very well.


A possible solution for using Jappix MiniChat with Openfire is to use this same approach and keep Jappix resident on the web page as the user browses from page to page. My way of doing this is to use a main top page container with the Jappix MiniChat which puts the content web page in an <iframe> tag. I then call JavaScript on the main top page from within the iframe to control Jappix.


Of course, this does not always work especially if the content page promotes itself to be the top main page for security purposes like Goole Mail for example. In practice, I use Jappix MiniChat with my own web applications and even if my web page is hijacked, cross domain security will stop malicious JavaScript controlling my application.


If this solution will work for you, then use the attached HTML file and adapt it to your needs.

I really like Jappix. It ia fully functional XMPP web client with a lot of features and even looks like Sparkweb



It has a cool microblog feature like onesocialweb similiar to the one I implemented on a comercial version of SparkWeb using XMPP pubsub. As much as I liked Jappix, I really could not use it. It was developed in PHP and required a second web server with too much fiddly configuration to make Openfire HTTP-BIND run the cross-domain gauntlet. Well that all changed when I discovered Quercus: Caucho Technology's fast, open-source, 100% Java implementation of the PHP language.


It has enabled me to create an Openfire plugin for Jappix that works out-of-the box. No configuration required.


The main reason for my interest in Jappix was the minichat feature which is like the Facebook IM User Interface and is best for integration with other web applications. I have an immediate requirement to put IM into my Clearspace/Openfire setup and Jappix was just right for this.



I am posting this here for community members who might have a need for it. I do not plan on doing any development work on the Jappix PHP code, so if you spot a fault, head over to the Jappix project web site and report it. Please don't email me.


How to install and use

  1. Download the appropiate zip file for your Openfire server
  2. Stop Openfire
  3. Unzip jappix.war and copy to your plugins folder
  4. Restart Openfire
  5. Go to http://your-server:7070/jappix


How to access the Jappix Admin Console

  1. Delete the contents of the OPENFIRE_HOME\plugins\jappix\store folder
  2. Go to http://YOUR_SERVER:7070/jappix



Download for Openfire-Jappix is

Source code is

Project Jappix is

Project Quercus is

Dele Olajide

Moving SparkWeb Forward

Posted by Dele Olajide Champion Jun 3, 2011

This is an update from ignite realtime community about where we are with SparkWeb


There is an Open Source HTML version of SparkWeb based on the original commercial Jive Software version and now released under the Apache 2.0 license just like Spark and Openfire. It can be found on the ignite realtime community here.




Knight Raider has worked on the Flash version of SparkWeb and has made it compatible with the ignite realtime latest version of XIFF. His version compiles with Flex Builder using Flex SDK 3.0  for Flash Player 9 and above. It can be found on the ignite realtime community here.


I have made a few more changes to make it compile with the latest Flex SDK 4.5 for current Flash Player 10.3 and above and uploaded it to the SparkWeb SVN. The code can be checked out using


Knight Raider has volunteered to work on this. We plan to to add Jingle-based audio, video, file transfer, screen sharing, etc and make it look better than this




Finally, work has started on RedSpark which is yet another web client for Spark, but is tightly integrated into Redfire and will be compatible with the Redfire plugin for Spark. It is extending XIFF with the new RTMP/RTMFP connection classes and has a Facebook/Google type chat user interface that combines both HTML5 and Flash to support a softphone (red5phone), audio/video in both 2-way and multi-user chat with screen sharing (red5-screenshare) and p2p file transfer using RTMFP.



I am currently looking at adding peer2peer support to Openfire using the Redfire plugin which has support for both RTMP and the new RTMFP (peer to peer) protocol from Adobe. I would like to get some feedback from the community to validate my thinking and confirm I am on the right track.


I know that I should be looking at Jingle and I also know I should be looking at XEP-0174: Serverless Messaging, but they don't serve my needs and the XMPP council had reservations about my RTMP ideas for Jingle because RTMP and RTMFP are considered proprietary. Unfortunately, Flash Player has not gone away and the open HTML5 websockets is still taking its first steps as a toddler.


I have developed a new client-side RTMFP connection class for XIFF that enables clients to dynamically become nodes or supernodes (like Skype) using RTMP and RTMFP. Nodes will connect and distribute messages to each other without a server using RTMFP, while super-nodes will connect to Openfire via the Redfire connection manager using RTMP and act as proxies for their neighbour nodes. Like Openfire clustering, disconnecting super-nodes are replaced immediately by election among the neighbour nodes.


XMPP Message packets between neighbours can be sent directly peer to peer if there is a route and server messaging logging is not mandatory.


In theory, a fully populated enterprise muticast 192.168.x.x network with aproximately 64K users would only need 256 Openfire socket connections




As a first step towards Openfire peer2peer, the latest version of the Redfire plugin for Spark has support for RTMFP. If there is a route between clients having a two-way chat or multi-user chat, then the audio and video is sent peer2peer using RTMFP. There should be some performance gains with multiple participants in a chat room. Screenshare and remote desktop control is still done via Openfire server using RTMP with Red5.

Dele Olajide

Red5 + Openfire = redfire

Posted by Dele Olajide Champion Jul 27, 2010

redfire is the future of the Red5 plugin for Openfire.


In an attempt to maintain a single version of Red5phone and keep Openfire (ver 3.7.0) in step with Red5 (ver 0.9.1), I have chosen to embed Openfire inside Red5 instead of the other way round.

I have posted the first version at


This first version is just only Openfire 3.7.0 beta running as a web application in Red5. You acess Openfire web console the same way. http://your_server:9090


I will be adding the improved redfire sparkweb client with latest versions of red5phone, red5screen-share and support for onesocialweb later on.

SAN JOSE, Calif. — Jan. 20, 2009 — Adobe Systems Incorporated (Nasdaq:ADBE) today announced plans to publish the Real-Time Messaging Protocol (RTMP) specification, more..


This is good news for the Red5 project and the Red5 plugin for Openfire with the Red5phone Flash phone. It will be interesting to see if the XMPP Standards council will give the Jingle RTMP Transport proposal another consideration.

After Gato made this suggestion in my last blog, I decided to move this request to the top of my to-do list as I also need it for another project I am currently working on.


How does it work?


I am using the Flex Dashboard developed by ESRIA which was donated to the Adobe Developer Connection. Plugins are presented in a pod layout called a View. Each View occupies a Tab in the SparkWeb ChatWindow. You can modify Views by dragging and dropping pods to a different location and minimizing, maximizing, and restoring pod windows. View changes are saved using a LocalSharedObject. View configuration data is loaded from sparkweb/plugins/plugins.xml with values in plugins.xml indicating which swf file to load for a particular pod within each View.



<view id="view0" label="Plugin Demo">
  <pod id="app01" title="User Moods" dataSource="plugins/moods.swf" />
  <pod id="app02" title="User Tunes" dataSource="plugins/usertunes.swf" />
  <pod id="app03" title="Demo" dataSource="plugins/demo.swf" />



SparkWeb will load each pod SWF file and call the method setParentApplication passing it the SparkWeb root Application object. From this object, you can navigate your way to access all other SparkWeb public objects and even add eventhandlers on events like NewMessage for example.


To get a feel of what can be done, I decided to implement the User Tunes and Moods PEP (personal eventing protocol) applications. See Armando Jagucki's blog for more details about PEP in Openfire. The source code to the demo plugins is in the src/plugins folder.


For those interested, the latest version of Red5 Plugin for Openfire can be found at _ Remove comments in plugins.xml to activate the demo.

The latest version of the Openfire Red5 plugin supports Openfire Fastpath and Webchat plugins from SparkWeb.


You can now use SparkWeb as a support agent to a workgroup queue and engage in a live support chat with a remote Webchat user on a website. It is fully compatible with Spark, but does not have all the Fastpath features of Spark yet.

It will also let a support agent start a Red5 audio/video conference or desktop share session with the remote user.


The requests will appear as Webchat co-browsing requests. The user clicks on the link to start the video conference in a web browser window.

Filter Blog

By date: By tag: