[Standards] Do we need STUN?

Kai Vehmanen kai.vehmanen at nokia.com
Fri Mar 9 11:35:01 UTC 2007


Hi,

On 08 March 2007 Matt Tucker wrote:

>required. What we're currently experimenting with is a pretty 
>simple derivation:
>
>1) Use the same ICE techniques for NAT traversal.
>2) As an alternative to STUN, try to get network address info 
>via XMPP first (since you already have a connection to your 
>XMPP server). Imagine the following (very simplfied and using 
>fake packet extension values,

I think what you are doing here is identical to transparent media 
relays in SIP (usually mentioned together with the marketing term SBC --
session 
border controller). An open-source example is the SER/OpenSER mediaproxy.

Essentially this is an alternative way to get the relayed candidate
instead of TURN: instead of client allocating the relay address, the
server does it on behalf of the client.

Now there has been long discussions about the merits of these approaches,
and the IETF community has settled on TURN. But, but, if you do go 
this road, at least add it as an extension to the ICE framework (so that the
standard mechanisms, like STUN, are used to test and choose between the 
available candidates). And really, you very quickly notice that you need
some
control packets (change of destination, framing of payloads, etc) that are 
sent over the media connection (from client to relay) and then you 
are on your way reinventing TURN already.

Definitely some help from the signaling is needed: what relays are
available and where, authenticating credentials you provide to the 
relay, etc.

Now there are _plenty_ of proprietary system implementing transparent
relaying, variants of STUN, of TURN, deployed at the moment, so obviously
you can make these things work. But I agree with other posters that
now is not the time to start writing new specs if the existing ones
can do the job, and potentially are used by other systems as well.

PS Btw, as for public STUN servers, stunserver.org is a good 
   reference (running the open-source 'stund' implementation available 
   from sf.net). 
PPS And as for difference between RFC3489 and 3489bis,
   see section 16 of 3489bis for a detailed list. Most of the changes
   only apply only to the usage of STUN to figure out the NAT behaviour.
   This functionality is not needed for ICE, and is now a separate
   spec:
   http://tools.ietf.org/wg/behave/draft-ietf-behave-nat-behavior-discovery/

-- 
first.surname at nokia.com (Kai Vehmanen)




More information about the Standards mailing list