[Standards] Re: Jingle bootstrapping

Matt Tucker matt at jivesoftware.com
Sat Mar 3 17:40:03 UTC 2007


Alex and all,

I'm a bit behind technically on the latest work Thiago has been doing.
So, my apologies for not bringing it up during the DevCon meeting. One
thing I did bring up was the alternative media proxy approach. If you
remember that discussion, the gist was that since we already have a
signalling mechanism with the XMPP server, implementing the media proxy
is *very* simple --  the XMPP server can just open the necessary ports
and tell the client what to use. Robert McQueen was going to investigate
the difficulty of actually implementing a TURN-based server over the
next several weeks so that we have it as a point of comparison. 

> the problem is to pass NAT and firewalls. Currently it looks 
> like STUN and ICE the best protocols out there. The problem 
> is that they are complex, and no ICE libraries are available yet.
> 
> We also discussed this in detail on the DevCon in Brussels. 
> Our conclusion was that we should evaluate all possibilities 
> out there, and also take a closer look at Teredo.

>From what Thiago told me yesterday, he's tested his technique to pass
through three levels of NAT devices. That's not bad. :) In any case, the
main point is that we see value in choosing techniques that work best
for the XMPP community. Just because it was defined somewhere else,
doesn't mean we have to use it (that's why we're not all using SIP).

I see several major (good) arguments for why we should focus on
ICE/STUN/TURN:

 1) The standards work is already being done by smart people.
 2) Libraries will be created to do this stuff, which will hide the
complexity.
 3) For things like media proxies, it's reasonable to assume that
vendors like Cisco will make some standard hardware we can interop with.

At the end of the day, those are all good arguments, but let me pick
them apart a bit.

> 1) The standards work is already being done.

a) The standards are still highly in flux and a moving target.
b) The existing standards work is bound by the constraints of SIP. That
may mean that we can create alternatives that are much simpler given an
existing XMPP stack.
b) From a market perspective, we're in a relatively narrow time band to
establish our relevancy. The SIP juggernaut marches on and we need to
clearly articulate the place for Jingle and its advantages. The argument
that we could exploit XMPP to create something better and simple than
what the SIP community is doing for NAT traversal really resonates with
me for that reason.

> 2) Libraries will be created to do this stuff, which will hide the
complexity.

These just don't exist yet. :) I think there are a couple reasons.
First, the standards like ICE are a moving target and people haven't
caught up yet. Second, it's mainly telcoms and large orgs that are using
this stuff. I think that's why there's still such relatively poor open
source support for STUN, which is a technology that's been around for a
long time. Finally, the complexity of the protocols is keeping people
away from doing implementations. 

> 3) For things like media proxies, it's reasonable to assume that
vendors like Cisco 
> will make some standard hardware we can interop with.

Given the points above, who knows when this will happen. :) By that
time, we'll likely have lost our chance to make Jingle relevant.


-------------------

I'd like to suggest the following:

 1) More people dive deep into the Jingle issues as soon as possible.
Yes, it's quite complicated, but having more voices at the table would
make the effort worth it.
 2) Continue experiments down all possible paths. We'll document some of
the techniques we're trying so that others can understand them more
clearly and try them as well. If Robert is able to do the TURN work,
we'll have that info as well.
 3) Set some clear goals for what we're trying to do with Jingle so that
we have some criteria to evaluate the different approaches. Just to get
the conversation started, here are some ideas (nothing particulary new):

 * Make Jingle NAT traversal easier to implement than any competing
technology.
 * Deliver working implementations and standards ahead of everybody
else.
 * Push Jingle to support a broad range of real-time interactions (not
just VoIP). That could include file transfer, screen share, etc.

Thanks,
Matt



More information about the Standards mailing list