[Standards] Do we need STUN?

Sean Egan seanegan at gmail.com
Thu Mar 8 18:12:25 UTC 2007


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