Openfire

By Tom Evans A few of you more intrepid Openfire fans may have noticed a bit of recent activity in one of the branches of the Openfire SVN repository. Well, some of your fellow developers have been working behind the scenes to provide clustering ... [More] support for PubSub, perhaps one of the lesser-known modules of our beloved real-time collaboration server. PubSub is an implementation of the XEP-0060 specification which extends the XMPP standard to add publish-subscribe functionality to the XMPP Core. However, if you have ever tried to use this module in Openfire, you may have been disappointed to discover that it was not designed to work in a clustered deployment. In fact, PubSub was forcibly disabled when deployed in a cluster! The main focus of the development effort was to address OF-205 and implement clustering support for the PubSub module. This work is now complete and the PubSub module is cluster-enabled and ready for action. My Kingdom for  a Cluster! However, during the course of this development effort, the team also took a critical look at the current clustering implementation itself (the "clustering" plugin). This solution is currently the only way to run Openfire in a clustered configuration (where multiple servers share the load). Unfortunately this plugin is inextricably tied to Oracle Coherence, an enterprise class (and enterprise priced) middleware component. A recent quote from Oracle put the price of Coherence (EE) at well over $300K for a smallish deployment ... clearly an untenable solution and incompatible partnership with the Openfire project. We looked around for clustering alternatives that would have better affinity with Openfire, and landed with Hazelcast (Community Edition). Hazelcast is an open source clustering and highly scalable data distribution platform for Java. It enjoys a large deployment base and is licensed under the community-friendly Apache 2.0 license. There are also commercial licensing options available for deployments where professional support and enterprise security (among other features) are must-haves. This looked like a perfect fit for our needs, and likely for the Openfire community as well. Where Two or Three are Gathered... We are pleased to annouce the immediate availabilty of a new Hazelcast-based clustering plugin for Openfire. Starting today in the trunk of the Openfire SVN repository you will find the new plugin (/src/plugins/hazelcast/). Note that you will need to also setup the latest version of the Openfire core (currently 3.7.2-Beta) to use the new plugin. We are looking for a few brave Openfire afficionados who can take the latest build and give it a whirl with your various deployment scenarios:How many users and/or cluster member nodes do you have?Which modules/components of Openfire are you using?What is your typical JVM configuration? Preferred OS? Network topology (load balancer, LAN/WAN, etc.)?Your feedback is very important and will help ensure that this new clustering solution will be a robust and stable component in the next Openfire release. Those who have wrestled with the existing clustering plugin will hopefully find the new solution to be much simpler to configure and deploy ... and certainly much lower cost! There is a README file included with the new Hazelcast plugin that documents the basic steps for setting up an Openfire cluster, including links to the supporting Hazelcast documentation (if needed). Testing ... Testing ... Is this thing on? Please take the new build for a spin and report your feedback here. We will be posting an article to the main community page before long, but would love to have some initial feedback from the core developers before engaging a wider audience. No doubt there will be some bugs and configuration glitches ... can you help us find and fix them? Thanks in advance for your consideration and assistance. Cross posted from http://community.igniterealtime.org/message/224947#224947 [Less]

I use the Phono SDK from Voxeo to enable phone calls from a web page on a couple of projects which include the Inspired-Social (WordPress/BuddyPress) plugin for Openfire. I like using Phono SDK, but it is dependent on external cloud servers in the ... [More] Internet that cannot be accessed in some situations. Recently on request, I had to modify it to work directly with an in-house Openfire server to provide Jingle voice calls over the RTMP and RTMFP transport as well as SIP calls to PBX phones. The result of that work is now available as Redfire-Phono which replaces the Red5Phone softphone in the Redfire plugin for Openfire. For more information about Redfire-Phono, see the latest release note for Redfire To test Redfire-Phono, visit http://redfire.4ng.net/redfire/phono/ and dial any sip phone address. It is connected to the voiptalk.org gateway and I can be reached on telephone extension 844263475 or sip address sip:[email protected].  I do not promise to answer the call [Less]

I recently started a project called jitsi-jingle primarily to add Jingle support to an audio-conferencing engine I was developing. It was also an opportunity to provide a replacement for the outdated smack jingle extension library (smackx-jingle) ... [More] using the Jingle implementation of the active Jitsi project. This however turned out to be more challenging than it sounded as the OSGI dependecies in Jitsi and the internal abstraction model to support multiple protocols like SIP and XMPP made the code extraction difficult. There is a soon to be released libjitsi which should make the task easier, but I am running out of valuable time (I do this stuff in my spare time), so I had to choose another option for my immediate first release.  Fortunately, there are alternatives. I had used phono from labs.voxeo.com on the inspired-social project. It has a Java applet which first started life as the IAX applet and is now the backbone to the phono java library. It has an excellent media engine and even supports Jingle internally, but from Javascript. I on the other hand, needed a simple Java Jingle library. Enter mini-jingle from Thiago Rocha, the original developer of smackx-jingle (while he was at Jivesoftware) and the architect of Jingle Nodes. Project mini-jingle is a simple, but working Jingle implementation minus the media engine which makes it a very good fit with phono-java-audio. By adding support for basic raw RTP UDP packets, the standard PCMU (ulaw) voice codec and the Openfire jingle-nodes plugin, I now have a working Jingle library for Smack that should work most of the time either directly peer to peer or via a Jingle nodes media relay plugin for Openfire. There will always be the exception cases of where UDP packets are completely blocked by a firewall. In order to test the library and put into practical use, I created a Spark plugin for it as a replacement for the old outdated Jingle plugin for simple voice calls between Spark users. When it is used with the Candy plugin for Openfire, it offers Spark users, group and private audio-conferencing from MUCs with Candy web clients as well. Just click on the telephone icon in the chat room toolbar. If you intend to use it, pick it up from here and remember to delete the old jingle plugin. Both won't work at the same time [Less]

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.

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 ... [More] 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. [Less]

Dear Community! Another year has passed for this open source project and various developers have contributed significantly to nearly all of our projects. We were able to finally release Openfire 3.7 and Spark 2.6.3 under Apache 2.0 license. The most ... [More] important Smack library has also seen several releases and last but not least the good old instant messaging gateway Kraken returned to us. Some great innovations were presented like SparkWeb/Redfire, Websocks and Candy. I really would like to thank all developers involved by contributing code and all users and system admins that went through this year. A very special thank you goes to Daryl Herzmann who keeps the servers healthy and Wroot for outstanding work in the forum. I would also like to single out Guus der Kinderen for his insights in Openfire architecture and the release of Openfire 3.7. Merry Christmas to all of you and a happy, healthy and sucessful 2012 [Less]

The Ignite Realtime community is happy to announce the release of version 3.7.1 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 ... [More] 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 3.7.1 release is primarily a bugfix release. Amongst others, these issues have been addressed:A number of enhancements were made to the server-to-server connectivity. Server-to-Server connectivity was enhanced and a bug preventing a successful dialback was fixed.Various improvements have been made to platform specific installers and scripts.The Multi-User Chat implementation has received various tweaks and updates.The full changelog is available on the Openfire project page. We welcome your feedback, suggestions, tips, hints, questions and other contributions in the Ignite Realtime Community pages. [Less]

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. Why?Recently, I have been involved in shaping an XMPP protocol extension (XEP) ... [More] 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.   How?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.jsWhere?http://code.google.com/p/openfire-websockets/ [Less]

  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 ... [More] 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. [Less]

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 ... [More] 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 https://svn.igniterealtime.org/svn/repos/sparkweb/trunk/SparkWeb2 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.  [Less]