[Standards] Do we need STUN?
stpeter at jabber.org
Sat Mar 17 03:43:03 UTC 2007
Robert McQueen wrote:
> 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.
While good flame war does help to clear the air once in a while, this
ain't nothing compared with the old days. Everyone is so *nice* now.
>>> 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.
Right. I think the lack of ICE implementations is temporary.
>> * 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.
I agree that we need some bootstrapping examples. At the next Council
meeting we'll discuss this:
It needs to be fixed up first, though.
>> * 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.
Right. Robert sent me his list of 8 Jingle actions used in OLPC and I'll
update XEP-0166 real soon now [tm] to integrate his feedback.
> 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
> 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.
Good points. In a way, it turns out that we've ended up preferring
stupid servers. Not sure how we ended up here, though. :)
XMPP Standards Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards