[Standards] Do we need STUN?

Robert McQueen robert.mcqueen at collabora.co.uk
Thu Mar 8 20:41:09 UTC 2007


Scott Ludwig wrote:
>> 3) Instead of implementing the TURN protocol to have to speak to a media
>> proxy, why not just get the media proxy info via XMPP? Some simple ideas
>> around this at:
>> http://wiki.igniterealtime.org/display/WILDFIRE/Wildfire+Media+Proxy
> 
> We need the client to resolve the relay server's dns address, in order
> to pick the relay server in the closest data center.
> 
> Now we have an ip address. We could talk to that server over xmpp
> (somehow using the ip address as the jid?), but it seems pointless
> once we have an ip address.

At any rate, TURN is just a few attributes to put into your STUN packet
in order to say "please send my media here". We've already got a working
STUN packet generator/parser in 500 lines of C or Python or whatever
takes your fancy, because we can re-use it for doing the external IP
determination/NAT port binding *and* ICE *and* talking to our relay
server. The XEP will be very short too, it will say "Jingle uses the
following standards", and people can easily find a library that will do
it for them.

We've already established that we're going to re-use RTP as an existing
sensible, well-thought out, proven and widely-deployed technology for
formatting audio and video packets. We've also presumably agreed that we
can use pre-existing audio codecs and don't need to start doing our own
analysis of what constitutes relevant voice data and what coefficients
and transformations we should use to send it. Clever people have already
gone before us, and done that work already.

So my question is, why the hell is everyone fixating on NAT traversal as
somewhere where we have to invent our own (apparently square, and
surrounded by angle brackets) wheel? This is bikeshedding to the highest
 degree, and it's really starting to aggravate me.

All of the proprietary IM systems invented their own media, streaming
and NAT traversal stuff 5 years ago, but recent versions of MSN, Yahoo
and AIM are dropping all of it in favour of SIP, RTP, STUN and yes, even
ICE based technologies. There are huge benefits to being able to re-use
the existing software implementations of RTP and friends, and this
applies just as well to the NAT traversal library too.

No matter how much you complain that the ICE RFC is long, or not
finished yet, it's going to be completed soon, it's going to carry a
massive amount of mindshare, and it's going to get far more
implementation, testing and support than any tin-can nonsense we come up
with. Furthermore, Google have already shown us that it works very well
indeed.

This is a chance for XMPP to do something very cool and gain a lot of
mindshare by adding the media calling functionality to the very solid
base of authentication/presence/messaging/etc that we've already built
up. 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.

It would be the saddest day of my life if I had to implement a seperate
plugin in our media library (Farsight) to support XMPP's home-made means
of NAT traversal, when all signs point to us now being able to re-use
the same plugin and code for SIP, MSN, Yahoo and AOL calls. The reason
we *have* plugins in the first place is because the proprietary IM
systems were doing some bogus non-standard stuff. I really didn't expect
that we'd be having to think about using it again for implementing XMPP
support.

We're not about to start writing our own audio codecs or streaming
formats, so why do we need to make life hard for Jingle client authors
by diverging from the established norms for things like NAT traversal?
Why is this even a question in people's minds? As Rachel says, the far
more interesting problems to solve are the ones that aren't solved
satisfactorily, like we know how to do NAT traversal with UDP packets,
now how do we transfer a file over it, and do we want to prefer that to
existing SOCKS5 stuff, etc?

Please stop this nonsense and stop trying to drive a wedge between XMPP
and established wisdom. A lot of the mailing list are agreeing with me
here. You really are very misguided.

Regards,
Rob



More information about the Standards mailing list