[Standards] Do we need STUN?

Robert McQueen robert.mcqueen at collabora.co.uk
Thu Mar 8 22:56:05 UTC 2007

Matt Tucker wrote:
> Ahh, nice. Peter and I were discussing over beer during the DEVCON how
> long it's been since a good series of flames happened on the lists.

Well, I'm trying to make a very firm point that this is the wrong
approach because I care about the XMPP community getting this right.

>> All you're doing here is coming up with myriad ways to put a lot of
> people off the adoption of 
>> Jingle by raising the cost and effort by forcing people into
> developing alternative implementations 
>> of these existing technologies.
> To imply that there's total consensus on ICE and Jingle and that we're
> simply trying to gum up the works is just not correct. What I see is:

There's going to be a lot of consensus behind where the SIP people go.
There are a lot of people who have already accepted that ICE is the best
way to go about solving NAT traversal and are just waiting for the IETF
to draw the line on the draft so they can get on and implement it. We
have a couple of implementations which validate the principle, Google's
already committed to bring libjingle up to date with the resulting
standards, and we're going to make sure that our Telepathy stack works
with it too, either with our own libnice, or using libjingle.

If we look at the number of RTP engines and codecs etc you can find,
there are plenty, and we've accepted that wisdom without question, and
I'm very sure that the same is going to happen with the NAT traversal
stuff. We're walking alongside a lot of people on a very well-trodden
path thus far, and trying to beat our own way off into the jungle isn't
going to do us any favours, and it will just make it harder for people
to walk with us.

>  * Every client author I know is having tons of problems getting their
> head around Jingle (hence the bootstrapping discussion). That makes any
> possible significant simplifications worthwhile to me.  

Right, but that's because what's happening *is* complex. The audio
streaming and NAT traversal etc all combine to present quite a hurdle. I
don't think what you're trying to do by trying to find a small portion
of it and come up with our own special way of doing it with an XMPP
server is going to reduce the complexity. If anything, as well as the
Jingle negotiation itself, it creates *more* work for the XMPP client
author to have to do on top of the media stack they're using.

>  * There's not even agreement on the proper number of states in Jingle
> yet (Peter's discussion about the possibilities of simplifying).

Yes, the simplification of the states/actions is something that's
ongoing and definitely very valuable, but that's at a different level to
the NAT traversal stuff we're talking about. We're following the
existing recipe for RTP audio/video with all of it's associated
complexity, because that's a solved problem. The Jingle state machines
are reasonably unrelated to the recommended/required method of NAT
traversal, which we agree needs to happen somehow and yes, it brings a
certain level of complexity to the table. That's why being able to
benefit from the others' efforts is essential.

>  * There are basically no good Open Source STUN server implementations.
> There are no Open Source TURN server implementations that I can find.
> Yes, they may be pretty easy to write -- my point is simply that it's a
> bit early too call this a solved problem that the whole industry has
> embraced. If that were truly the case, we'd see more bits out there.

libjingle itself also contains a STUN server *and* a relay server
implementation. This aside, there are also a vast number of existing
*deployed* STUN servers, and they're free to use. Google runs one at
stun.l.google.com, which libjingle uses by default. If you pick up any
SIP client it comes with a list of 100s of STUN servers you're free to
use, and almost all SIP operators will provide one for their customers
too. I didn't find any evidence of any "UDP Echo" servers when I looked
either, open source *or* deployed, nor any XMPP servers which will give
me my IP address. If we're trying to make a decision of whether we
should start from a standstill and move in our own direction, or join up
with others and push in the same direction as them, the answer's quite
clear to me.

> At the end of the day, we'll implement whatever is the community
> consensus. At the same time, it seems pre-mature to rail against
> protocol ideas that haven't even been documented yet. Why don't we keep
> the discussion open for a few weeks and objectively evaluate new ideas?
> If STUN and TURN are the real deal, they'll easily stand up to any
> alternatives.

The alternative that I object to is the idea that by somehow involving
the XMPP server, we can improve the situation for clients. That's
unfortunately a fallacy. I appreciate the XMPP philosophy of keeping
complexity on the server side so the clients can be simpler, but that's
not something that applies here. You can't do peer-to-peer media
streaming with a data form. We're already requiring that the client
author finds an implementation of a certain amount of complexity with
the implementation of RTP and streaming.

Whilst I agree that yes, the NAT traversal mechanism is not a totally
solved problem, it's something that the industry has been converging on
for a good decade or so, and ICE has a lot of weight behind it as
representing the state of the art in established wisdom about how this
problem should be solved. By making client authors interact with the
XMPP server to do something special rather than letting the client
author delegate this bit to existing or iminent implementations, you're
actually forcing everyone to do more implementation work, not less.

The second reason involving the server is a bad idea is that you
increase the dependency on the existence of these suitably-enlightened
servers. XMPP servers are already very very widely deployed and as we
learnt from the uptake of SOCKS5 bystreams proxies, a large number of
servers won't be changing their behaviour in any significant fashion for
 a long time. As it stands, by simply relying on servers as routers of
IQs, anyone on any server can pick up libjingle or Telepathy and make a
call to anyone else on any server, provided they've got access to one of
the myriad public STUN servers (Google's included). Any step you take to
involve the server in hooking you up in magical ways (use XMPP instead
of STUN, ICE or TURN) will just make the protocol more fragile and harm
its adoption.

> Regards,
> -Matt


More information about the Standards mailing list