[Standards] Do we need STUN?

Thiago Camargo thiago at jivesoftware.com
Thu Mar 8 19:03:34 UTC 2007


Sean,

Anyone here wants to re-invent nothing. I really don't understand all these worries about stopping using STUN server to discover public address of a client and why clients needs to negotiate directly with the STUN/TURN server.

Yes, ICE is the best way, btw, why not use ICE algorithm without using several protocol?

Hey, I really don't understand what you mean with this paragraph:
"Perhaps there are some corporate firewalls blocking STUN specifically,
by blocking UDP port 3478. Google Talk doesn't use port 3478 for STUN,
but instead communicates the port number through the "Jingle info"
protocol (http://code.google.com/apis/talk/jep_extensions/jingleinfo.html)."

You still use a STUN port! Corporate don't care about how you discover the port number, they just blocks the port that you're using.
Corporate don't open your Jingle packet read and open the port you sent in your "Jingle info"
protocol (http://code.google.com/apis/talk/jep_extensions/jingleinfo.html).

I totally agree with your paragraph:
"Bluntly put, it is outright impossible to create a high-quality,
peer-to-peer, out-of-band, UDP connection entirely within a
server-centralized, in-band, TCP, XMPP stream. The most popular
complaints about ICE (it's complicated, it's taking so long to develop
within IETF)."

You're completely right. But why clients need to implements STUN? Why? If sometimes it's not necessary?

Best Regards,
Thiago

-----Original Message-----
From: standards-bounces at xmpp.org [mailto:standards-bounces at xmpp.org] On Behalf Of Sean Egan
Sent: quinta-feira, 8 de março de 2007 15:12
To: XMPP Extension Discussion List
Subject: Re: [Standards] Do we need STUN?

On 3/8/07, Thiago Camargo <thiago at jivesoftware.com> wrote:
> STUN Works well but it takes too much time to detect public address, and are usually blocked in corporate networks,

Do you have research that backs up these claims? STUN takes a single
round-trip to the server to discover your "server reflexive" (to use
ICE terminology) address, which should certainly be on the order of
milliseconds. (TCP requires more round trips than this just to
connect!) It's been our experience at Google that essentially 100% of
the time, our ICE transport has successfully negotiated the highest
possible quality connection well before the recipient has hit
"Accept."

Perhaps there are some corporate firewalls blocking STUN specifically,
by blocking UDP port 3478. Google Talk doesn't use port 3478 for STUN,
but instead communicates the port number through the "Jingle info"
protocol (http://code.google.com/apis/talk/jep_extensions/jingleinfo.html).

If corporate firewalls are blocking all UDP outright, you're not going
to be able to get your RTP through any more successfully than STUN.

In either case, Google Talk has been very well tested in a huge
assortment of network topologies, and we've found that STUN used in
conjunction with ICE is successful in breaking through NATs and
firewalls over 90% of the time. Where STUN doesn't work is more likely
restrictive NATs that are incompatible with STUN than corporate
firewalls blocking STUN packets.

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

I would argue that your "completely XMPP solution" makes Jingle
implementation harder for people who don't know "your completely XMPP
solution," which is currently a considerably larger set than that of
people who don't know ICE (what does SIP have to do with this?)

Bluntly put, it is outright impossible to create a high-quality,
peer-to-peer, out-of-band, UDP connection entirely within a
server-centralized, in-band, TCP, XMPP stream. The most popular
complaints about ICE (it's complicated, it's taking so long to develop
within IETF), are due to the fact that NAT traversal is a complicated
problem. ICE is currently the best solution, and trying to reinvent it
would be a fool's errand.



More information about the Standards mailing list