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:
!http://www.igniterealtime.org/blog/wp-content/uploads/2007/03/banner.png!
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:
-
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).
-
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.
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 ).