[Standards] Do we need STUN?
thiago at jivesoftware.com
Thu Mar 8 17:25:26 UTC 2007
There is XMPP Software with STUN usage, including GTalk and Smack-Jingle from Jive Software.
STUN Works well but it takes too much time to detect public address, and are usually blocked in corporate networks, and makes jingle implementation harder to people who don't know SIP/ICE, which don't make any sense.
What we are trying to find is a completely XMPP Solution, and use STUN/TURN just in server side when it's necessary.
Anyway, I think that STUN will be necessary is some cases in server side.
From: standards-bounces at xmpp.org [mailto:standards-bounces at xmpp.org] On Behalf Of Evgeniy Khramtsov
Sent: quinta-feira, 8 de março de 2007 10:37
To: standards at xmpp.org
Subject: [Standards] Do we need STUN?
Do we really need a STUN support in Jingle implementations?
Of course, we need some methods for NAT traversal, but why this must be
Recently I've started to develop a STUN/TURN server and found out some
drawbacks of this protocols:
1) Lack of protocol stability.
Currently RFC3489 does not have much sense and there are exist only
deeply drafts of 3489bis.
2) Lack of integration with XMPP services.
I don't see any methods how to authenticate XMPP-users on the STUN/TURN
This is the main problem. I completely disagree with guys who say that
STUN is simple.
Furthermore, I think that STUN is *unfairly* complex. I don't see the
of a lot of things. Also, the RFC3489bis authors are trying to save the
compatibility with it predecessor:
no doubt, there are a lot of SIP software with STUN support, but is
there exist one for XMPP?
I just wonder if it possible to modify XEP-0065 and to adapt XEP-0176
More information about the Standards