Skip navigation
1 2 3 ... 13 Previous Next

Ignite Realtime Blog

183 Posts

Hi there, I'm Smack's new maintainer. Some of you may know me already as the maintainer of aSmack, the Android port of Smack. I first like to thank Robin for his work on Smack in the past.


Smack has a long development history. The first recorded commit dates back to Jan 13 2003. Now, over 11 years later, we are going make fundamental changes to Smack in order to ensure that it will last another decade.


Most importantly: Ignite Realtime is applying as Google Summer of Code organization. We propose a project to modernize and modularize Smacks build system. One reason why this is necessary, is that we want Smack to be able to target Java SE and Android. Read more about it here.


Smacks SVN repository has been migrated to git, and the code is now hosted on GitHub. We are currently evaluating hosting the code in our own Atlassian Stash, but that isn't decided yet and is not a high priority right now.


Let's have a look at Smack's contributors of the last 11 years:


   513  Gaston Dombiak

   474  Matt Tucker

   123  rcollier

   105  Thiago Camargo

   104  Florian Schmaus

    69  Alex Wenckus

    46  Bill Lynch

    43  Derek DeMoro

    24  Günther Niess

    15  Daniel Henninger

    12  Henning Staib

    11  loki

     7  Michael Will

     7  Wolf Posdorfer

     7  guus

     6  Holger Bergunde

     6  Jeff Williams

     5  Jay Kline

     4  Marilyn Daum

     3  Francisco Vives

     2  bruce

     1  (no author)

     1  Andrew Wright

     1  Pete Matern

     1  Tim Jentz

     1  root


Hopefully this list will grow over the time. If you'd like to contribute bigger patches to Smack, please consult the developers. Either via IRC #smack (freenode) or via the developers forum. All patches will be reviewed, since there are usually a few things that should be improved before the commit is ready for Smack's master branch. Make also sure to read the Guidelines for Smack Developers and Contributors.


Besides the GSOC project, there are more goodies in the queue, like XEP-0198 Stream Mangament and Roster Versioning.


We also work on migrating the build system to gradle, including deployments to sonatype/maven central. I expect the next release to be available as jar and via maven central.


Finally, shortly after the 3.4.0 release, a memory leak was reported in the forum. The cause was identified 6 hours later, and a fixed nighlty release was made availabe shortly after. I am going to use this importand fix as reason to release Smack 3.4.1 today, in order to get familar with the release process of Smack.


Yesterday's release of Openfire 3.9.0 had some problems with packaging of the release.  Bouncycastle signed jar files were getting packed, which then caused problems when Openfire attempted to load them.  We have hopefully fixed this issue and cleaned up a few other details and are proud to announce a 3.9.1 release!


Openfire is a real time collaboration (RTC) server licensed under the Open Source Apache license. It uses the only widely adopted open protocol for instant messaging, XMPP (also called Jabber). Openfire is incredibly easy to setup and administer, but offers rock-solid security and performance.


The download page offers these files and here are their md5sums for your comparison.






Please report any issues to us in the forums.  We are always looking for developers to help improve Openfire, so please let us know if interested!


The Ignite Realtime community is happy to announce the release of version 3.9.0 of Openfire! Downloads for various platforms are available here.


Openfire is a real time collaboration (RTC) server licensed under the Open Source Apache license. It uses the only widely adopted open protocol for instant messaging, XMPP (also called Jabber). Openfire is incredibly easy to setup and administer, but offers rock-solid security and performance.


There are a few important fixes with this release, be sure to checkout the changelog for more details.


As always, we welcome your feedback, suggestions, tips, hints, questions and other contributions in the Ignite Realtime Community pages.


We are also looking for people interested in helping to develop Openfire!  If you enjoy hacking at Java code and would like to pitch in, please let us know on the forums.


Update 6 Feb 2014 20 UTC: There was a problem with the initial build of 3.9.0 and the packaging of the bouncycastle libraries.  This has been fixed.  The following MD5 checksums should be used to check the files you download.





Stepping Down as Lead

Posted by rcollier Feb 2, 2014

It is with a heavy heart that I am stepping down as the project lead for Smack. 


I am happy to have managed to push out 6 releases in the last 3 years, but even from the start I always had issues finding the time to dedicate to this project.  Things have never really improved on that front.  Three young children and some unexpected illnesses in my family haven't exactly made for a lot of free time over the last couple of years. 


I have been thinking about this for awhile actually, but it has only been this year that some other eager contributors have come along with a lot of ideas and motivation for the project. So that makes for a good time to step aside and let those with time and dedication move the project forward.


I still plan on contributing when and if I can, but it will probably be less code and more helping others in the forums.  It takes much shorter blocks of time.


So, I wish the best of luck to Flow, who will be taking over my role as project lead.


Smack 3.4.0 is released

Posted by rcollier Feb 2, 2014

The Ignite Realtime community is happy to announce the latest release of Smack (version 3.4.0).  It is now available for download.  This release has a number of noteworthy changes.

  • Deployment structure - Changes reflect the idea of only keeping code that matches specifications that have gone at least as far as the Draft state in the smack or smackx jars.
    • Workgroups - This has been pulled out of the main jars and placed on it's own due to the fact that the spec it is based on hasn't reached the Draft status of the XEP process.  It was in fact moved to the Deferred state in 2005, and is not likely to ever move forward.
    • Experimental - New artifact to hold code that has not reached the Draft status of the XEP process.  It currently contains the new contribution for XEP-0280 - Message Carbons.  Due to the expectation that the specifications that this code is base on will be in a state of flux until being moved forward to a Draft state, this jar will have it's own versioning scheme.  Users should be aware that this code is apt to have API changes and such outside what can be expected of changes to the major version of Smack.  It may be more volatile to major changes and should be used with caution. Code deemed experimental will be 'promoted' once the specification has reached the Draft state.
  • Logging - Smack now uses Java util logging.  Prior to this release, what little logging was done consisted of dumping to the system console via System.out/err calls and the infamous printStackTrace calls.  Although it is not the most popular of logging libraries, it does not create any external dependencies and can be used in conjunction with either Log4j or Slf4j.
  • Configuration
    • Provider Management - Fixed the long standing issue ( SMACK-286) of not being able to change how and where providers are loaded from.  The loading of providers from a specific file location has been pulled out of the ProviderManager.  The manager is now only responsible for managing the providers, not loading them as well.  The API has been augmented to allow for users to provide any means they wish to load providers.  A file based one which loads the current file format is provided, so any existing files can be easily added.  This can be utilized via the API or a VM argument.  The documentation has been updated to reflect these changes, please read for more details.
    • Initialization - System initialization can now be accomplished programmatically via additions to the SmackConfiguration API or by using the new a VM argument.  The default behaviour remains the same though, so you don't have to actually do anything unless you want to change the initialization process or the default system properties.  This easily enables developers to only initialize the functionality they want to use. Please read the documentation for more details, and a sample configuration file is now provided in the samples directory of the deployment archive.


Here is a partial list of some of the fixes beyond the ones related to the aforementioned items.

  • SMACK-387 - Allow configuration of ChatManager for handling incoming messages.
  • SMACK-403 - Add support for XEP-0297 Stanza Forwarding.
  • SMACK-343 - Fixed OSGi manifests.  All jars are fragments of smack.jar.
  • SMACK-339 - Allow ConnectionListeners to be added before Connection is connected.


In addition to these changes, there have been many bugs fixed and a variety of other tasks done, the complete listing can be viewed here.


The Jitsi project have just announced that Jitsi Videobridge is now compatible with WebRTC and can be used as a central relaying point for web video conferences (or web+Jitsi). You can check out shot of a first prototype here. A big thank you to Emil Ivov,  Philipp Hancke ( and Lyubomir Marinov ( for making this happen and sharing it with the rest of us


I was keen to see this in action with Openfire as Jitsi Videobridge works fine as an Openfire plugin and it will add the much needed and anticipated video streams forwarding/relaying feature to WebRTC applications as Red5 does to Flash Player. I copied all the required files to my Openfire server, made some minor adjustments for Openfire and as you can see below, it works!!



However it is early days. This is all leading edge code still in development. Jitsi Videobridge as an internal component from an Openfire plugin does not yet work because the bouncycastle library in Openfire needs an upgrade to the latest version that supports DTLS-SRTP. It only worked as an external component. I will try to get this fixed for Openfire 3.9.0 which is currently in alpha.


** UPDATE **


Jitsi Videobridge plugin for Openfire is now available here at with the webrtc-based video conferencing application embedded as a web service. A complete web muti-person video conference solution in one box. You will need Openfire 3.9.0 to try it out.


In the meantime, Claude Stabile has generously made a live version available for us to try at




The first draft of the COnferences with LIght BRIdging (Colibri) XEP that is used to manage video conferences with Jitsi Videobridge is now out. You can find it here. All we need now is a volunteer to setp forward and add it to Smack/aSmack and Spark using the Java bells library




The first version of the Jitsi jitmeet web conferencing application is now out and has replaced the demo web application in the Jitsi Videobridge plugin. It has MUC chat with some other needed features like mute audio/video. Expect some more before Openfire 3.9.0 is released. As usual, you can checkout the latest code in the ignite realtime VCS, build and try it out yourself.


To help those cannot build openfire 3.9.0 from source. Do the following


Grab Openfire 3.9.0 nightly build from here

Download jitsivideobridge.jar file from here





There is now a dedicated ignite space for jitsi-videobridge plugin. Please post any issues, questions and contributions here. I have also posted a blog about the changes I have made to the plugin to support a server-side focus agent.


As many know, there has been a push in the community to move our VCS from subversion to git.  I agree with them that it is time to make that move, and I hope the other contributors and especially the project leads will get on board. I had reservations about making this move myself, not so much specific to git itself, but for the fact that I didn't think that it offered enough advantage over the cost of actually doing the move due to the limited resources available.  If we were all paid to do this kind of work, these issues simply wouldn't exist.  It isn't simply switching version control, but the interactions between that and the existing infrastructure (Jira and Bamboo) and the like and also implementing new software, build and release processes.


With regards to the software development process, this is where git, or more specifically, some of the available management tools for git really shine. They add more than enough value to the process that I think we should adopt them.


So, I am proposing that we get and set up Atlassian Stash (the enterprise version of BitBucket).  It has excellent integration with the existing development tools we are using and will provide a much better software development and management process then we currently have (which admittedly isn't that hard).


  • Branches can be linked to their Jira tickets.
  • Code review of a pull request will automatically update a Jira ticket to code review status.
  • Accepting a pull request will update the status to resolved.
  • Configure builds to automatically build any branch.
  • Force merge of pull request to require a successful build before allowing a merge.
  • Inline code reviews
  • Would allow private repos
  • Can be branded to Igniterealtime


From what I know, the feature set is very similar to Github, but I don't know where Github stands with respect to Jira and Bamboo integration. I am sure the build server has no issues either way with simply building the code base, but I have no idea if it offers any actual integration the other way around.


Smack 3.3.1 is released

Posted by rcollier Oct 7, 2013

The Ignite Realtime community is happy to announce the latest release of Smack (version 3.3.1).  It is now available for download.  This is a minor release and there have been a few bug fixes, most importantly, the memory leak in the keep alive process and one new feature. This is a partial list of the more important items.


  • [SMACK-441] - Memory leak in KeepAliveManager
  • [SMACK-447] - Compression is not enabled for Java7ZlibInputOutputStream
  • [SMACK-448] - Java7ZlibInputOutputStream does not work. Deflater.DEFAULT_STRATEGY is used as compression level when it should use Deflater.DEFAULT_COMPRESSION
  • [SMACK-450] - VCard.load() throws null pointer exception if there is no VCard for the user
  • [SMACK-455] - Multiple items doesn`t not parse correctly in a pubsub message
  • [SMACK-369] - Exceptions during login should get thrown back up to the caller.


In addition to these, there have been many bugs fixed and a variety of other tasks done, the complete listing can be viewed here.


For anyone following my projects, you would be aware of me using  jVoiceBridge as my audio conferencing and VOIP engine with Openfire. I stopping using Asterisk a while back and all my telephony is done with jVoiceBridge and the SIP plugin for Openfire. The combination of Openfire, jVoiceBridge and WebRTC provides a very compact unfied communications solution.


One of the many cool features of jVoiceBridge I was never able to exploit up until now was the spatial audio feature that creates a 3D audio immersion experience from a stereo mix.


What's so cool about this?


As a home worker, I have been dreaming of when I would get to hear the separation of conference participant voices across a stereo field. By adding matching visual sitting postions, speech detection and improved voice quality, we might just get audio-conference calls back in fashion.


What makes this now possible is the use of the OPUS codec in WebRTC. However for a while, it looked like it was going to remain a dream unless I could figure out a way to access WebRTC audio streams directly from an Openfire plugin.


Introducing the Relay Plugin for Openfire.


I started out with the source code to the JingleNodes plugin for Openfire and got the WebRTC UDP packets wired into jVoiceBridge conferences. At first, I was limited to 8K mono audio from the PCMU (ulaw) codec, but thanks to the Jitsi project, I was able to add their OPUS decoder/encoder and finally got 48K stereo samples streaming into jVoiceBridge.




How does it work?


I have put together a demo web page of the plugin running on my server. To test, you have to access the same page from at least two PCs in order to test the 3D audio-conferencing effect. It only works with Google Chrome.


It will let you do the following things


  1. Join the demo conference choosing a codec and position on the stereo field (-90 to 90)
  2. Add a telephone call (SIP address) into the demo conference. OPUS re-sampling does not work with all SIP phones, use PCMU if you get no audio.
  3. Send DTMF to the telephone call.
  4. Watch the speech detection events
  5. Mute your audio from the conference


Where do we go from here?


The plugin will be an official Openfire plugin and the project will be hosted and supported from Igniterealtime. I am planning on exposing all the features of the plugin through the new Rayo XMPP Extension for remote call control. I hope to develop a Strophe plugin for Rayo to enable easy access from XMPP based web applications.


If you are interested in joining up with me to make this all happen sooner than later, send me an email or private message.




The Igniterealtime servers reside at Contegix ( ) thanks to the generous support of Jive Software ( ). Between 3-7 UTC on 21 July 2013, the servers will be offline to allow them to be physically moved to a new facility.  The actual downtime may be shorter or longer than that period.  Please comment on this post if you see degraded services after that period.





The Ignite Realtime community is happy to announce the release of version 3.8.2 of Openfire! Downloads for various platforms are available here.


Openfire is a real time collaboration (RTC) server licensed under the Open Source Apache license. It uses the only widely adopted open protocol for instant messaging, XMPP (also called Jabber). Openfire is incredibly easy to setup and administer, but offers rock-solid security and performance.


This release adds BOSH functionality for setting CORS headers and improves Pub-Sub support. There is also a new Atlassian Crowd provider!  Various stability improvements were made as well. The changelog lists these and other changes in more detail.


As always, we welcome your feedback, suggestions, tips, hints, questions and other contributions in the Ignite Realtime Community pages.


Now that Firefox Beta has WebRTC enabled by default, it was time to upgrade the WebRTC audio/video demo to support Firefox. Even though changes were minimal and I could do Firefox<->Firefox as well as Chrome<->Firefox, there is still an outstanding issue that is a show stopper for me.




Firefox does not yet support trickle ICE candidates and consequently does not work with Jingle Relay Nodes. This means we cannot use Openfire to act as a media bridge and relay media when both WebRTC peers cannot connect directly with each other as we can do with Chrome.


I am hoping this will be fixed before formal release in June. In the meantime, you can test it at Just make sure you have Firefox beta or latest Chrome browsers. As usual, source code is attached for those curious to see or reuse in their own applications.


Smack 3.3 is released

Posted by rcollier May 4, 2013

The Ignite Realtime community is happy to announce the latest release of Smack (version 3.3).  It is now available for download.  There have been a large number of issues addressed for this release, including new functionality with support for several more protocol extensions (XEP's) and many improvements on existing features.

        New Features

  • [SMACK-331] -         Add support for XEP-0184: Message Delivery Receipts
  • [SMACK-345] -         Inproved detection of last activity
  • [SMACK-361] -         Add support for XEP-0115 Entity Capabilities
  • [SMACK-376] -         Setting a custom trust manager to control certificates from outside
  • [SMACK-388] -         XEP-199 XMPP Ping support


In addition to these, there have been many bugs fixed and a variety of other tasks done, the complete listing can be viewed here.


A new version of the Jappix plugin for Openfire is available with support for WebRTC restored back. It only supports Chrome version 26+ and is compatible with the WebRTC plugin for Spark. It uses The Openfire JingleNodes plugin for media relaying via Openfire server when WebRTC peers can connect directly with each other.


Video Chat


Group Video Chat


How to use

Click on the webcam icon to share video in an active chat/groupchat.


With chats, the other party receives a prompt to share their audio/video.


Groupchat does not prompt and auto shares audio and video with all participants.


For those following the use of Openfire for audio and video communication, The Jitsi project released very recently, the VideoBridge plugin for Openfire. If you use Jitsi with Openfire, you find it very useful for creating both audio and video conferences with multiple people.  I am hoping someone will try and make a Spark plugin for it


In the meantime, I did a quick experiment to see if I could convert the Redfire plugin for Spark to use WebRTC instead of RTMP/RTMFP



Guess what!!. It worked


It works the same way as the Redfire plugin for Spark. Click on the webrtc button to share audio and video with the person you are chatting with. On the other side, that person will receive a prompt to accept or reject the offer.



So here it is attached, if you want to play with it. It does not depend on any Openfire plugin, but will use the JingleNodes plugin if available to relay WebRTC audio/video media when a direct connection cannot be made between two Spark clients..


It needs Google Chrome version 26+ running on the client desktop as the default browser. It supports Google Chrome frame for Internet Explorer. The source code is in there as well. When Firexfox WebRTC support becomes stable, I will probably add support for that too.


*** UPDATE ***

I finally got multi-user video conferencing working in group chat like Redfire. Please note that there is no prompt. Each participant MUST click on the webrtc button to join the video conference and the plugin ensures a webrtc peer-connection is made between each and every participant. This should be done after everyone joins the groupchat.


If a new person enters the room and wishes to join the video-conference, each participant should close their browser windows and click on the webrtc button again.

1 2 3 ... 13 Previous Next