[Standards] Proposed XMPP Extension: STUNServerDiscovery forJingle

Matt Tucker matt at jivesoftware.com
Mon Mar 26 22:54:38 UTC 2007


Kai,

> To me, this is as simple as the mechanism you described, but 
> with the added bonus that the service provider can use an 
> off-the-shelf TURN server. I admit there are very few of 
> these servers out there at the moment, but now that the specs 
> are about to be finished, that situation is certain to change.

Is this really true? The TURN server and XMPP server will need to be
integrated *somehow* in order to coordinate the shared secret. Not only
that, but the current TURN spec seems to assume a static shared secret,
which would be a security problem in most environments. I think that's
why Google uses a shared secret that times out after a regular period.
These considerations make the "off the shelf" argument less relevant,
especially given there are no off the shelf TURN servers right now.

Interestingly, Google isn't even doing TURN, although their solution is
TURN-like. Also, I found the following article interesting:
http://www.sipcenter.com/sip.nsf/html/AG+P2P+SIP. A snip:

--------
*NAT traversal using distributed media relays*

SIP clients should have ICE support and try to exchange RTP packets with
the remote User Agents by using STUN techniques described by ICE
methodology.

If ICE capability does not exist or does not work, a TURN solution will
be used as follows. In contrast to the TURN protocol definition, the SIP
Proxy and not the User agent does the session reservation for the media
stream relay. This has the immediate advantage that the SIP UA does not
have to have any TURN capability built in and secondary a database with
user credentials does not need to be stored on both the TURN server and
the client.

The TURN server has a trusted relationship with the SIP nodes. Another
advantage that led to this approach is the fact that the SIP Proxy has
always more clues about where is the best place to assign a media relay
in between a SIP session than the UA itself. This allows per call
allocation of a media relay session in an optimum place on the Internet
and solves the load balancing and scalability of the media relay
function.
--------

In other words, this is a SIP implementation that does TURN allocation
for the client in order to remove complexity on the client side. :) If
we can't beat that in XMPP, that would be a sad thing.

> >It will make clients implementations much easier. And the 
> type of the 
> >relay Server will be transparent.
> 
> It won't be transparent - you have to specify how to perform 
> the initial media path authentication, how do you set the 
> destination of your media packets (where the relay will send 
> packets to), how to perform TCP relaying, etc -- i.e. you 
> anyways have to specify some relaying protocol.

The signaling over XMPP would be quite simple (as Thiago suggested in
his last email), and the nice thing is that it would be close to
transparent to the media layer -- in other words, you just tell your
media implementation to start sending bytes to a certain place and you
don't have to worry about TURN authentication, etc, etc.

-Matt



More information about the Standards mailing list