Skip navigation
All Places > Ignite Realtime Blog > Author: Dele Olajide
1 2 3 4 Previous Next

Ignite Realtime Blog

50 Posts authored by: Dele Olajide Champion

I use Openfire and SparkWeb everyday and recently starting evaluating Clearspace to power the community I am building for my wife's education consultancy (www.inspiredfutures.co.uk). As I had limited computing power and memory to work with on my hosted server, it became expedient that I needed to integrate all three products under the same web server and Java JVM.

 

The first thing I did was to make an openfire plugin out of Clearspace

The next thing I did was to enable SparkWeb display an HTML page from its chat container

http://red5.4ng.net/gtms/Image14.jpg

 

The result is what you see above and I am very pleased with it (chuffed as we say in the UK). The benefits of integrating Openfire and Clearspace has already been mentioned here . Adding SparkWeb to that combination in order to have realtime messaging, desktop sharing, Red5 audio/video calling and a SIP phone makes a compelling case for me to use Clearspace

 

I have reservations about real-time integration with web applications that use the MVC model based on Stuts like Clearspace or even PHP applications like SugarCRM. Even Salesforce.com also falls into the same group because they all build their UI on the server and everytime the user does anything that requires a server fetch, the screen goes all blank while you wait for the whole page to be rebuilt from server-side Java code.

 

Putting a softphone or an IM client as a widget in these applications requires constant connect/disconnect cycles as the user moves from page to page. It reminds me of my attempt to build a real-time application on an Apple iPhone and a softphone in Salesforce.com. What we need is to be able to keep our widgets UI resident on the client as well as the user session in the plugin on the server. I am curious to see how Jive Software implements the realtime widgets in Clearspace.

 

In the meantime, I am happy to make SparkWeb my container for real-time web applications as I am getting biased towards Adobe's open-source Flex as my de-facto web client application development platform. I learnt a lot from studying the SparkWeb code and I am planing on developing some Clearspace widgets that use SparkWeb's features through the Javascript External Interface to make the integration complete.

 

If you want to use SparkWeb as a container for your web applications as I have done, pick up the latest version of the Red5 plugin from here. Copy and edit index.html. Change the httpLabel and httpURL parameters to your preference.

When SparkWeb became open-source, I took a look at the source code and found it had more features than the Flex-based XMPP client I was co-developing for the Red5 Plugin. It therefore made sense to migrate the Flash audio and video features we had developed for our client to SparkWeb and make it compatible with the Spark and Openfire Red5 Plugins and package it as part of the Red5 plugin. The downside to this that the modifications to the Red5 version of SparkWeb makes it out of sync with the official SVN and it could possibly become a fork requiring a name change later on.

 

So what does the Red5 SparkWeb offer?

 

  1. A plugin container for SparkWeb. I noticed  that quite a number of users are asking for a plugin to deploy SparkWeb. My advice would be to try the Red5 Plugin.

    Configure  Index.html and point your users at

    http://your_server:nnnn/red5_webapp_name/sparkweb

    Where nnnn is your HTTP-BIND port number (default 7070) and red5_webapp_name is your default red5 web application name (default red5)

  2. Enables use of the Red5 plugin audio and video features with both Spark and SparkWeb. You can't do video messaging and the video roster is replaced with visual presence (see below). You can make audio/video calls and share your desktop with your contacts. Each call record is logged in openfire and can be queried by the administrator with the Openfire SIP plugin.

  3. Makes SIP phone calls between Spark and SparkWeb users. All SparkWeb SIP calls are logged with the Openfire SIP plugin as well.

  4. Provides webcam support. If you have a webcam installed on your PC, it will be automatically detected and will be used instead of your vcard photo. You can disable this in index.html. You can add or replace your vcard photo with a snapshot of your webcam when you edit your profile. You can also publish snapshots from your webcam as visual presence to all your contacts. What this means is that all your contacts will have  a snapshot of your webcam in their rosters. The interval between snapshots is 60 secs by default and can be modified in index.html. See a draft copy of my proposal to extend XMPP with visual presence. Please feel free to post comments at the bottom of the document.

I also made a few cosmetic changes to my taste and added sound effects for incoming calls and instant messaging. I added some code to improve the loss of focus detection by tracking Flash application activation/deactivation messages and mouse movement. If you use Internet explorer and enable pop-ups, you will get a pop-up in the bottom right corner of the screen with a photo, name and first line of the incoming messaging if you are outside of SparkWeb when a new message arrives.

 

I am hoping to add fastpath support and a calendar to SparkWeb next.

Just over a year ago, I blogged about using audio and video with openfire. At that time, I implemented a SIP based softphone in Adobe Flash using AsteriskWin32 and VAC4. My argument for an open-source, standards based, no-install web-based softphone as a requirement for Web 2.0 voice applications is still valid today and the emergence of Ribbit, TringMe, Zingaya (Flashphone) and others confirmed my thinking was not isolated.

 

It has however been a disappointment that all implementations I have encountered to-date have been closed, proprietary and inaccessible for integration (both client and server).

 

The latest release of the Red5 Plugin for Openfire features a completely open-source implementation of a web-based SIP softphone written in Flex3 and should work on both Windows and Linux. It uses MjSIP as the SIP user agent in the plugin and should work with most SIP proxies, but I have only tested with Asterisk. I have also only tested 2 simultaneous users, but there is no limit and will depend on how many users and media streams Red5 can cope with before it dies. Each telephone conversation consumes 2 user RTMP connections and 4 audio streams on Red5. All source code is provided and you are free to use it in your Openfire Red5 Plugin applications. Just confirm that the open-source licenses of MjSIP and Nelly2PCM are to your liking.

 

 

I have also integrated the softphone into SparkWeb and the Openfire SIP plugin. This will enable a user to make SIP calls from Spark and SparkWeb with the same user profile. The old Red5gateway will be depreciated and in a later release for window users, I will be adding AsteriskWin32 to the plugin and provide a complete SIP solution for Openfire.

 

As usual, any feedback will be appreciated.

 

For details of how this works read on.....

 

 

The red5Phone Flex3 client makes a NetConnection with the Red5 SIP application. When it recieves a success response, it makes a remote "open" method call in the Red5 SIP application which creates a pair of SIPUser and RTMPUser objects for that user and instructs SIPUser to register the user with the specified SIP proxy. When the NetConnection is closed by the Flex3 client, the pair of objects are destroyed and the user is unregistered from the SIP proxy.

 

When the Flex3 client invokes "call" remotely, SIPUser starts a SIP outgoing call with the SIP proxy and exchanges RTP audio streams. It invokes "connected" on the Flex3 client and informs it of what stream names Flex3 client should use to publish from the PC microphone and play to the PC speaker. It then resamples the incoming audio RTP packets from 8KHZ to 11KHZ, converts from ulaw to ADPCM and calls a method in the RTMPUser object to publish the audio to Red5 using the same name it gave to the Flex3 client to play.

 

The RTMPUser objects also plays the stream being published by the Flex3 client which is in the Nellymoser ASAO codec. It calls asao2ulaw (my modified version of the open source nelly2pcm) to convert the packets to ulaw and pass to SIPUser through a PipedOutputStream.

 

An incoming call follows the same pattern, the incoming SIP signal appears as a remote "incoming" call on the flex3 client. The user can then pickup the call and the Red5phone Flex3 client remotely calls "accept" in SIPUser to accept the call. The audio is setup the same way as an outgoing call.

A few moons ago, there was a request from some Spark users in igniterealtime for a desktop screen sharing plugin. I did mention at that point that I had done something in the past using Red5 and a screen-capture webcam called VH Screen Capture Driver and that I would dig it out of my archives and put it into a future release of the Red5 plugin.

 

I have since discovered that this approach has a few drawbacks. It is not bandwidth efficient, will only work on Windows and although the video driver is free, it is not open source. What we needed was for Flash on the desktop to capture the screen as images, send them to a server and re-assemble them back into a video feed which is then published by Red5. Despite my best efforts, I have since not been able to work out how to do this and if anyone has any tips and clues, please tell me. It will be appreciated.

 

In the meantime I stumbled on Openmeetings in the Openlaszlo community. It is an online meeting collaboration tool developed by Sebastian Wagner with a number of usefull tools like video, white-board and of course screen-sharing. The video sharing is java-based and does not require any software install other than (the java runtime environment) JRE 1.4+. It uses the same java technique (java.awt.Robot class) as Spark to take a screenshot. It goes one step further by pushing the captured screen shots at a regular interval to a web server using the http upload feature. In the spirit of Open Source and re-useability, I have now decided to use Sebatian's approach and keep the images on the web server and allow multiple clients to view with an auto-refreshing webpage instead of my original intention to convert into a video feed for Red5.

 

I have added this feature to the latest version (0.0.10) of the Red5 plugin. It includes the server-side image upload support, the viewer webpage and the Openmeeting screen publisher application as a java webstart application. Both publisher and viewer can be accessed from the Spark red5 plugin and JWChat. You select the publisher from the menu to publish your desktop screen and you right click the roster context menu to view the desktop screens of your contacts.

 

As usual, all feedback is welcome.

As the lead developer of the web-based version of a voice trading system used world-wide by some of the largest financial organizations, I have learned one or two things about web-based VoIP applications. When we designed our trading application, web-based VoIP was not ready for the 99% reliability and quality demanded for financial transactions. We therefore decided to keep the voice on a regular telephone (POTS) and used the web browser to handle the real-time signaling and associated data using a push method called pushlet.

 

My work on the Red5 plugin for Openfire is a personal attempt to investigate alternative communication technologies and get involved in the open source community. I could not have picked a better place than the Igniterealtime community. It will be interesting to see what happens when Adobe release their own VoIP enabled Flash client, but until then Flash and Red5 in my opinion is still the best way to do web-based VoIP applications.

 

The telephone landscape is changing. It's less about exclusive voice communication and more about real-time collaboration where voice is just one of the many communication channels used to do effective collaboration. I believe presence is a very important ingredient that brings intelligence to finding the right channel to communicate with one or many contacts in real time. This is a vision that I share with Jive Software and that why I endorse and work with Openfire on a personal basis. The plugin approach on both server and client is a very smart idea and has enabled me to integrate Flash and Red5 with Spark and Openfire with little or no effort. Implementing HTTP-binding in Openfire was icing on the cake and enabled me to add audio and video to a web-based client like JWChat with relative ease.

 

This brings me to the purpose of this blog.

 

At the moment, Spark users get a choice of SIP, Jingle and Red5 for voice. These features enable Spark to make calls to SIP phones, XMPP users and web-based XMPP users. SparkWeb does not do VOIP yet, but that will change when Jingle supports a web-compatible transport.

 

Web-based XMPP users could not call SIP phones until now.

 

I have designed a gateway (audio bridge) which converts red5 calls to and from SIP. I have now implemented a version for Windows XP/2k3 using Asteriskwin32. The basic engine is an ActiveX component written in Visual Basic and the source code is open. To solve the problem of transcoding the proprietary Nellymoser codec to SIP, I have used 8 pairs of virtual soundcards provided by a commercial product called VAC (Virtual Audio cable). It is very popular and has been used on other projects to bridge Skype for example.

 

I now have tight integration between Openfire, Red5 and Asterisk and this has lead to a new version of the Red5 plugin which can control the red5Gateway and implement some interesting ideas. For example, the gateway makes it possible to make every user and group JID become a public SIP address. The gateway will route and convert all SIP calls for user@domain.com to a red5 call. In reverse, if you make a Red5 call to an extension nnnnnn, the gateway will convert it to SIP and pass it on to your configured SIP service provider to route. In the case of group@example, Asterisk is used to hold the caller in a queue while every group member is called until someone answers.

Red5 gateway support is disabled by default on the Red5 plugin, as it is an optional component and is not part of the red5.war file. I am in the process of creating a hosted server to demo it over the next few weeks. If your Openfire runs on Windows and you are interested in trying it before then, send me an email and I will send you the link and documentation as soon as I finish writing it.

 

In the meantime, enjoy the latest version of the red5 plugin 0.0.7 which is now compatible with Openfire 3.3.0 and Spark 2.5.1. It has the latest Red5 server code: 0.6RC3. I tried to downgrade it to java5, but it was incompatible with Openfire, so I gave up trying :(. I have added support for viewing vcard avatars. I will add the ability to upload images in the next release so you will need Spark to upload the photographs/images for now. As I use jwchat5 myself, I have made the chat UI much like Pandion style, which I like. I only got one bug report from the previous release and have fixed it.

 

A big thanks to everyone at Igniterealtime, especially the folks at Jive who have added Red5 support duties to their already busy day jobs.

 

As always, all feedback positive or negative helps to motivate an open-source development and influence product design. The current version 0.0.7 is still far from 1.0.0, so please keep the comments coming.

 

-dele

 

Filter Blog

By date: By tag: