Skip navigation
All Places > Ignite Realtime Blog > 2012 > February

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.

Release of Smack 3.2.2

Posted by rcollier Champion Feb 6, 2012

The latest version of Smack is now available for download.  There have been several bugfixes related to file transfer and minor improvements in this version.


Barring anything being broken specifically by this release, the next version of Smack will be 3.3, there are no plans for a 3.2.3 version.


Here is a list of issues resolved in this release.


  • SMACK-263 -         Set file info in all send* methods
  • SMACK-338 -         IBB filetransfer doesn't work as expected
  • SMACK-346 -         Bug in return code for rejection handling in FileTransferManager
  • SMACK-349 -         Smack's IBB sends too much data in a packet
  • SMACK-350 -         Bytestream is not working in Spark 2.6.3 from XP to W7
  • SMACK-353 -         Thread leak in the FaultTolerantNegotiator
  • SMACK-354 -         Provide milliseconds in timestamp colum debugwindow
  • SMACK-322 -         NPE in XMPPConnection
  • SMACK-324 -         Investigate SASL issue with jabberd2 servers
  • SMACK-348 -         Documentation error - broken link
  • SMACK-362 -         smack throw NoSuchElementException if the muc#roominfo_subject has no values
  • SMACK-343 -         Make Smack jar an OSGi bundle.


NOTE: The documentation links have not been updated yet, but the jar files are available.

Filter Blog

By date: By tag: