[Standards] Do we need STUN?

Thiago Camargo 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.


-----Original Message-----
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 
exactly STUN?
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 
3) Complexity.
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 
for this.

More information about the Standards mailing list