powered by Jive Software

Ring Ring!

With today’s releases of Spark 2.5.0 Beta 4 and Smack 3.0.0 Beta 3, support for Jingle VoIP has officially landed. We’re pretty excited about the progress so far (and perhaps Thiago can start to get more sleep after numerous all-nighters). Some highlights:

  • We’ve tested NAT traversal in a wide variety of environments, in one case punching through three layers of NATs.

  • Voice quality is sounding great on Windows and Mac. Note that we haven’t had a chance to test on Linux testing yet, so support there is probably broken at the moment.

Of course, there’s a ton of work still: more NAT traversal and media proxy tests, UI refinements, entity capabilities detection (so we know when to show the call button), Linux testing, options to use more than just the GSM codec, etc. We’re working towards a final 2.5.0 release of Spark in the next several weeks, with a final Smack 3.0 release at roughly the same time.

NAT traversal isn’t an easy problem to solve, but we’ve come up with some innovative twists to standard ICE techniques that we believe are superior. In essence, we’ve found a way to bypass the limitations of SIP (which doesn’t have reliable signaling like XMPP) and therefore don’t require STUN and TURN support. For those of you that don’t read pages and pages of VoIP RFC’s in your spare time, this probably all sounds like gobbledygook – my apologies. Some specifics of our proposal are already being discussed in the XMPP standards list. We’re now hard at work fully documenting the protocol and then will submit it for review (which will be a controversial process). Will we as the XMPP community have the courage to break from the SIP mold and standardize better and simpler techniques for NAT traversal?

Jingle: Too late or Perfect Timing?

All this Jingle work has made me reflect on the market realities of VoIP in XMPP. After a lot of hype last year, discussion of Jingle had quieted down a lot. Jingle excitement seems to be building again recently, but can we truly make an impact against SIP? Two things make me hopeful:

  • NAT traversal through open standards is not a solved problem yet. ICE, STUN and TURN are still draft standards and not many SIP stacks have deployed all these new protocols yet. That makes me believe that we have a window of opportunity to establish mindshare for Jingle as the best NAT traversal VoIP protocol.

  • SIP federation just doesn’t exist in any useful way yet. Instead, SIP is generally deployed in isolated islands. On the other hand, XMPP federation is vibrant and growing at a huge rate. That may give Jingle a leg up.

Greg and I are heading to the VON conference next week. We’re printing a huge sign to put up in the booth:


It will be interesting to see how people react. If you’re going to be at the conference, be sure to stop by the booth and say hi!

The voice conferences we’ve attended this year have been a mixed bag for Jingle. We saw good interest in the protocol at E-Tel, although many bristled at the notion that XMPP could solve any problems better than SIP/SIMPLE. On the other hand, those I talked to at the Internet Telephony conference generally hadn’t even heard of XMPP, much less Jingle.

For Jingle to succeed, a few things need to happen:

  1. We need to clearly articulate where Jingle fits into the VoIP puzzle and make sure we offer some clear advantages over SIP for those puzzle pieces (note that it’s never been a goal of Jingle to replace SIP in all cases).

  2. Interoperable Jingle implementations need to start appearing as soon as possible.

I find it all to be an exciting challenge and I can’t wait to see where Jingle is a year from now.

So Jingle is available in the Mac version? That would be great! In an earlier post you said the mac version will follow later… Can’t wait to try it out!

the UI looks a lot slower than the previous releases… is it just me or …?

Nevertheless, it’s a great piece of software, keep up the great work!


What version of the Jingle protocol is used? The one in Google Talk, the one described in the XEPs, or both?

RE: “Jingle: Too late or Perfect Timing?”

I would say the reason for jingle losing it’s hype from last year is no one has released a product (sans google) that takes advantage of it. So here is hoping you guys are the pioneers in the OSS arena to get this taking off

I already called using Coccinella’s Jingle support several months ago… http://hem.fyristorg.com/matben/

Magnus: we’re using the latest version of the protocol, although with our own twists to the ICE negotiation as mentioned in my blog post. Google has said they’ll move to the official Jingle protocol once it gets a bit further in the standard process.

fabieuse: we had to hack some libraries to make Mac support, but a few users are reporting that things work well. I would still consider it a bit experimental unitl we get a chance to test more.

sander: good to hear that you had Jingle support 9 years ago. You’re using libjingle? That’s great, although libjingle doesn’t do the actual updated Jingle protocol yet and still has lots of Google Talk custom extensions. The thing we’re excited about is that our stack is an entirely fresh Jingle client implementation (the first we know of). It should greatly help interop testing as more Jingle clients come online.



So is there any intercompatiblity to other clients?

And how about Jingle File Transfer, anything in the making ?

Greetings from Germany,


@Matt: No, Coccinella does not use libjingle it also uses a fresh Jingle implementation. Mats wrote his own implementation and it should be compatible with any other Jingle client that implements the specs correctly. So, Jive guys do not think you were first with a fresh implementation :stuck_out_tongue: Note that Coccinella uses IAX for transporting the media, so if Spark supports IAX, it should be compatible with Coccinella (this also counts as a feature request ).

btw: Coccinella also supports the Wildfire-only specification for Asterisk.

sander: My apologies for the mistake! No, we don’t support IAX. That will likely never be a standard Jingle mechanism. Do you guys plan to support the more standard stuff? If so, we’d love to do some interop testing.

marc: it’s still too early for interop with other clients, but it should start to happen soon. As for file transfer – the standards proposals are still being heavily debated within the XSF. Hopefully there will be progress soon.

We now have two phone icons in Spark. Dial and Call. Any plans to consolidate them??.

I tried to make a Jingle call to the GTalk client on my Nokia 770 and it failed miserably. Looking forward to when I can do that soon…



no matter which proposal the XSF decides for- i hope it’s one that works. on my setup, google talk is the only client that allows me to transfer files. so my choice would be jingle

SIP federation is alive and well in the higher ed community - SIP.edu has over 250,000 users reachable. Now we just need get all those users reachable via XMPP.

10 drafts born around SIP while 1 line is written for jingle, I wonder where will be jingle when google leaves it. SIP is replacing everything in the legacy telco world.