[Standards] Do we need STUN?

Sean Egan seanegan at gmail.com
Thu Mar 8 20:00:53 UTC 2007

On 3/8/07, Thiago Camargo <thiago at jivesoftware.com> wrote:
> 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.

They're not so much "worries" as "recommendations." As long as you
manage to get a server-reflexive candidate that's likely to have an
appropriate NAT binding for all but the most restrictive NATs, nobody
really cares how you get it.. It just seems that *the* way to do so is
STUN, and it's silly to do something else.

The important thing to remember about ICE is that it's interactive:
both peers work together to create the best possible connection, and
if either peer is suboptimal, both peers suffer. The concern is that
if such important software as Wildfire and Spark do something
suboptimal (even if by accident), that it will adversely affect the
entire network.

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

Personally, I'm unaware of any firewall that parses every UDP packet
sent to detect for STUN, and specifically blocks it. My experiences
with Google Talk show that such firewalls are extremely rare.

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

ICE requires that you inject STUN binding requests/responses in the
RTP stream (as connectivity checks). The concern is that if you want
to avoid forming and parsing STUN packets for NAT binding, that you
also want to avoid doing it in the RTP stream. While generating
candidates with some other protocol does not break compatibility with
the Jingle ICE transport, avoiding STUN within the RTP stream will
break interoperability.

More information about the Standards mailing list