[Standards] Do we need STUN?
matt at jivesoftware.com
Thu Mar 8 19:43:20 UTC 2007
Rachel and all,
> But the debate, as far as I can
> tell, should be about / that/ -- about what the state of XMPP
> stream initiation is -- not about whether or not Jingle
> should use STUN and ICE. Those are part of firewall/NAT
> traversal, and the entire point of Jingle is that it
> negotiates streams that traverse a firewall or NAT.
I think the "debate" is getting a bit confused. ICE is a set of
techniques to do NAT traversal. It uses STUN for public address/NAT
discovery and TURN when media proxies are required. What we're currently
experimenting with is a pretty simple derivation:
1) Use the same ICE techniques for NAT traversal.
2) As an alternative to STUN, try to get network address info via XMPP
first (since you already have a connection to your XMPP server). Imagine
the following (very simplfied and using fake packet extension values,
<iq type="get" from="user at server.com" to="server.com">
<iq type="result" to="user at server.com" from="server.com">
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:
We're very sensitive to "not invented here" syndrome; we're not going to
do something different just to be different. However, I reject the
argument that we're not smart enough as a community to examine all the
issues and choose the best approach for XMPP. NAT traversal is a
confusing topic, but it's not rocket science.
We're busy documenting everything we've been experimenting with so that
others can look at it and offer their feedback. We hope that will be
done next week. Otherwise, there's no rush. ICE probably won't be
finished for another few years, heh heh.
More information about the Standards