powered by Jive Software

Jitsi-Jingle and Openfire-Ringo


#1

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

Jitsi-Jingle

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

Openfire-Ringo

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

Update

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 = Packages.org.jivesoftware.util.Log;

var interceptorMgr = Packages.org.jivesoftware.openfire.interceptor.InterceptorManager;

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

{

      if (processed) log.info(packet);

} }

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

interceptorMgr.getInstance().addInterceptor(myInterceptor);

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


#2

Jingle update is a must.

Ringo is very interesting…


#3

I only just saw this. Nice work!

In that regard, we will soon be releasing *libjitsi. *It will have all the media features from Jitsi but without the OSGi stuff, so it would be usable from any Java application. Spark would also be a good use case.

Thought this might be worth noting here. If interested, just subscribe to any of the news channels on http://jitsi.org


#4

Thanks for the kind words and information about OSGi. I am have started work on this and the OSGi integration is proving a challenge, do this is good news.


#5

Dele, would you consider simply creating the new jingle project as a smackx-jitsi project within smack. Perhaps we can simply drop the current xmackx-jingle project altogether in a future release in favor of your implementation.


#6

That was the original plan, but it proved to be more difficult that it sounded :slight_smile:

I am back to plan A to updating smackx-jingle with the relevant bits from jitsi


#7

In that regard we will probably be releasing a first version of libjitsi in two or three weeks. FYI.


#8

That is good news. I will wait for libjitsi before I make my next move :wink:


#9

Hey all, we haven’t announced this officially, but we wanted to give you folks an early notice:

We have now officially spinned off the new “libjitsi” media library. You can use it to add audio, video, zrtp encryption, multi-party audio mixing and many, many others.

We have also switched the Jitsi nightly builds to use libjitsi (rather than the code itself) so the lib should be relatively stable.

We think Spark would be a great use case!

You could pick up the project at the jitsi repositories on java.net. Here’s the exact URL:

https://svn.java.net/svn/jitsi~svn/libjitsi

Feedback is most welcome on the Jitsi dev mailing list.

Cheers,

Emil


#10

Emil,

Thanks for the notice and early access to libjitsi. I will most certainly take a look.

Do you have plans to add support for WebRtc ?


#11

Hey Dele,

Given how webrtc is supposed to become rtcweb and how the latter is still in the works, I don’t think we would be spending substantial effort there. At least not for the time being.That said, as far as I understand the paradigm, media level compatibility should be there automatically. The compatibility of which parts were you interested in?

Besides libjitsi is currently a media framework only. It is especially designed for applications like Spark and Jitsi that already handle the signalling.

As for the jingle part itself, we’ve built this on top of smack and the code still lives in Jitsi. We’d be happy to integrate and contribute it to smack if there’s interest in this.

Cheers,

Emil


#12

Hi Emil,

My understanding is that Webrtc is a media only framework like libjitsi and Google would like to keep it that way despite the difference of opinion with the rtcweb “telecoms” group. The jury is still out on the final decision. There are already 100% Javascript implementations of Jingle and SIP signalling in the public domain.

Webrtc currently supports SRTP wiith AES_CM_128_HMAC_SHA1_XX encryption with non-standard STUN/ICE messages. This will change to DTLS later, but the debates are still ongoing. I suspect AES support will be kept for quite a while.

I already have a working audio conferencing engine that uses my first version of jitsi-jingle and is compatible with webrtc for the SRTP packets. I added some code to handle the non-standard STUN/ICE messages, but that will have to be modified when Webrtc fully supports rfc5245. I might use your ICE4J library then

I plan to keep the mini-jingle library for Jingle signaling. I am however keen to know that if I switch my media framework to libjitsi from phono-java-audio, I can keep my current webrtc compatibility for Candy, SparkWeb and other XMPP Web clients.


#13

Hey Dele,

Yes, we do support SRTP in libjitsi and use it in Jitsi for both SDES (what many refer to as regular SRTP) and ZRTP.

Regarding ice4j, we already have support for Google’s STUN, TURN and ICE variants since Jitsi is able to conduct calls with Gmail and the Android client.

As for the Jingle part, it’s relatively thin compared to the media and ICE parts but if at some point people consider it useful (given how mini-jingle’s last commit is from three years ago), we’d be happy to work on integrating it in smack.

Cheers,

Emil


#14

Hi Emil,

From your response, it seems that with a bit of effort, it should be possible to make libjitsi work with the current implementation of Webrtc in Google Chrome. I shall give it a try

It seems we have 3 choices to take advantage of your Jingle implementation which is in active development

  1. You integrate back your Jingle changes to the official smackx-jingle library. It will make the task of upgrading Spark to be Jitsi (audio only) compatible very straight forward with a few minor changes to the existing Jingle plugin. This also involves you integrating libjitsi into smackx-jingle.

  2. We deprecate smackx-jingle and you develop a new smackx-jitsi library with libjitsi integrated. Any one else can develop a new Spark plugin that offers the full Jitsi Jingle communication user experience (video, audio conferencing, screen share,etc)

  3. Integrate back only your Jingle changes to a new smackx-jitsi-jingle type library. Some one else would have to take the smack extension library with libjitsi to either update the Spark jingle plugin or develop a new one from scratch.

I think you are hinting at the third option


#15

Hey Dele,

I was indeed mostly thinking about the signalling part. We can start by simply adding the packets, the providers, and various elements to smack itself. I don’t quite see why we need a separate lib for them.

Once we are done with those, adding to Spark the glue code that manages smack, libjitsi and ice4j can happen later.

It could be me, someone else from the Jitsi community (when we find the time), or someone else entirely. After all, they can look for inspiration in or entirely copy the same code from Jitsi. The point is that it would be easier to handle this as separate steps.

Emil


#16

Thanks Emil,

I completely agree with you


#17

I have already posted this on the jitsi dev mailing list, but adding it here as well

It was straight forward to replace phono-audio-java with libjitsi and keep mini-jingle. However, when I run my test application. I get exceptions with the source code downloaded from the link supplied

It would seem that some packages are missing (org.jitsi.impl.configuration.*)

[java] java.lang.IllegalStateException: FrameworkUtil.getBundle

[java] at org.jitsi.impl.libjitsi.LibJitsiOSGiImpl.(Unknown Source)

[java] at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

[java] at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessor Impl.java:39)

[java] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructor AccessorImpl.java:27)

[java] at java.lang.reflect.Constructor.newInstance(Constructor.java:513)

[java] at java.lang.Class.newInstance0(Class.java:355)

[java] at java.lang.Class.newInstance(Class.java:308)

[java] at org.jitsi.service.libjitsi.LibJitsi.start(Unknown Source)

[java] at org.minijingle.xmpp.smack.RawUdpJingleClient.loggedIn(RawUdpJingleClient.java:4 5)

[java] at org.minijingle.xmpp.smack.Client.login(Client.java:30)

[java] at org.minijingle.xmpp.smack.RawUdpJingleClient.(RawUdpJingleClient.java:40)

[java] at org.minijingle.xmpp.smack.RawUdpJingleClient.main(RawUdpJingleClient.java:195)

[java] java.lang.ClassNotFoundException: org.jitsi.impl.configuration.ConfigurationServiceImpl

[java] at java.net.URLClassLoader$1.run(URLClassLoader.java:202)

[java] at java.security.AccessController.doPrivileged(Native Method)

[java] at java.net.URLClassLoader.findClass(URLClassLoader.java:190)

[java] at java.lang.ClassLoader.loadClass(ClassLoader.java:306)

[java] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)

[java] at java.lang.ClassLoader.loadClass(ClassLoader.java:247)

[java] at java.lang.Class.forName0(Native Method)

[java] at java.lang.Class.forName(Class.java:169)

[java] at org.jitsi.impl.libjitsi.LibJitsiImpl.getService(Unknown Source)

[java] at org.jitsi.service.libjitsi.LibJitsi.invokeGetServiceOnImpl(Unknown Source)

[java] at org.jitsi.service.libjitsi.LibJitsi.getConfigurationService(Unknown Source)

[java] at org.jitsi.impl.neomedia.device.DeviceSystem.initializeDeviceSystems(Unknown Source)

[java] at org.jitsi.impl.neomedia.device.DeviceConfiguration.(Unknown Source)

[java] at org.jitsi.impl.neomedia.MediaServiceImpl.(Unknown Source)

[java] at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

[java] at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessor Impl.java:39)

[java] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructor AccessorImpl.java:27)

[java] at java.lang.reflect.Constructor.newInstance(Constructor.java:513)

[java] at java.lang.Class.newInstance0(Class.java:355)

[java] at java.lang.Class.newInstance(Class.java:308)

[java] at org.jitsi.impl.libjitsi.LibJitsiImpl.getService(Unknown Source)

[java] at org.jitsi.service.libjitsi.LibJitsi.invokeGetServiceOnImpl(Unknown Source)

[java] at org.jitsi.service.libjitsi.LibJitsi.getMediaService(Unknown Source)

[java] at org.minijingle.xmpp.smack.RawUdpJingleClient.loggedIn(RawUdpJingleClient.java:4 6)

[java] at org.minijingle.xmpp.smack.Client.login(Client.java:30)

[java] at org.minijingle.xmpp.smack.RawUdpJingleClient.(RawUdpJingleClient.java:40)

[java] at org.minijingle.xmpp.smack.RawUdpJingleClient.main(RawUdpJingleClient.java:195)

[java] 09-Jul-2012 16:22:02 org.jitsi.util.Logger info

[java] INFO: Initializing audio devices

[java] 09-Jul-2012 16:22:02 org.jitsi.util.Logger info

[java] INFO: Initializing video devices

[java] 09-Jul-2012 16:22:02 org.jitsi.util.Logger info

[java] INFO: Looking for configured audio devices.

[java] 09-Jul-2012 16:22:02 org.jitsi.util.Logger info

[java] INFO: Scanning for configured Video Devices.

[java] 09-Jul-2012 16:22:02 org.jitsi.util.Logger info

[java] INFO: Found Desktop Streaming 0 as a AVFRAME, class org.jitsi.impl.neomedia.codec.video.AVFrame, pixFmt= -1 video capture device.

[java] 09-Jul-2012 16:22:02 org.jitsi.util.Logger error

[java] SEVERE: Failed to register custom Renderer net.java.sip.communicator.impl.neomedia.jmfext.media.renderer.video.JAWTRendere r with JMF.

[java] java.lang.UnsatisfiedLinkError: no jnawtrenderer in java.library.path

[java] at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1738)

[java] at java.lang.Runtime.loadLibrary0(Runtime.java:823)

[java] at java.lang.System.loadLibrary(System.java:1028)

[java] at net.java.sip.communicator.impl.neomedia.jmfext.media.renderer.video.JAWTRendere r.(Unknown Source)

[java] at java.lang.Class.forName0(Native Method)

[java] at java.lang.Class.forName(Class.java:169)

[java] at org.jitsi.impl.neomedia.device.DeviceConfiguration.registerCustomRenderers(Unkn own Source)

[java] at org.jitsi.impl.neomedia.device.DeviceConfiguration.(Unknown Source)

[java] at org.jitsi.impl.neomedia.MediaServiceImpl.(Unknown Source)

[java] at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

[java] at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessor Impl.java:39)

[java] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructor AccessorImpl.java:27)

[java] at java.lang.reflect.Constructor.newInstance(Constructor.java:513)

[java] at java.lang.Class.newInstance0(Class.java:355)

[java] at java.lang.Class.newInstance(Class.java:308)

[java] at org.jitsi.impl.libjitsi.LibJitsiImpl.getService(Unknown Source)

[java] at org.jitsi.service.libjitsi.LibJitsi.invokeGetServiceOnImpl(Unknown Source)

[java] at org.jitsi.service.libjitsi.LibJitsi.getMediaService(Unknown Source)

[java] at org.minijingle.xmpp.smack.RawUdpJingleClient.loggedIn(RawUdpJingleClient.java:4 6)

[java] at org.minijingle.xmpp.smack.Client.login(Client.java:30)

[java] at org.minijingle.xmpp.smack.RawUdpJingleClient.(RawUdpJingleClient.java:40)

[java] at org.minijingle.xmpp.smack.RawUdpJingleClient.main(RawUdpJingleClient.java:195)

[java] 09-Jul-2012 16:22:02 net.sf.fmj.registry.Registry commit

[java] INFO: Wrote registry file: d:\documents and settings\803292695.fmj.registry.xml

[java] makeCall: florence.olajide@btg199251/Spark 2.6.3

[java] Fetching xmpp server jingle node relay channel

[java] Received:

Terminate batch job (Y/N)?


#18

Hey Dele,

Someone will answer on our dev list as well, but for the sake of completeness: you don’t need the configuration service. That exception is harmless and we’ll make sure it is not displayed any more.

As for the other exceptions, you will need to make sure that the native files in the lib directory are in your library path.

Hope this helps!

As for the Jingle integration, who do we need to talk to in order to get this committed?

Emil


#19

Thanks for the response

For Jingle Integration, you need the Smack lead developer. It used to be Matt Tucker, but I think @Robin Collier has taken over on a part time basis like every else around here

He probably is listening to this thread as he asked a question earlier on

Dele, would you consider simply creating the new jingle project as a smackx-jitsi project within smack. Perhaps we can simply drop the current xmackx-jingle project altogether in a future release in favor of your implementation.


#20

I see,

So, @Robin, do you agree with the Jingle integration we discussed? That is, adding the packet and provider classes to smack and then leaving the rest for a bit later?

Emil