[Standards] Proposed XMPP Extension: STUNServerDiscovery forJingle

Matt Tucker matt at jivesoftware.com
Wed Mar 28 16:23:59 UTC 2007


Kai,

> Yes, transparent media relaying is widely used in existing 
> SIP networks. It has its pros and cons. One very huge plus is 
> that it solves the NAT problem for existing SIP client base, 
> and that's why it is used a lot (but this is not an issue for 
> XMPP). A big minus is that the proxy-relays cannot verify 
> whether direct connectivity would work, and you end up 
> relaying more traffic than you would with ICE-enabled clients.

I think the article I had sent said their solution was for the client to
use ICE and *then* to use transparent media relays. In any case,
Thiago's solution doesn't preclude ICE whatsoever. Here's what I'm
seeing:

 * Server-negoiated relays are incredibly easier for the client to
implement. The back-end could be TURN or whatever relay server protocol
we want to use.
 * This solution will not work for Google due to their world-wide server
network and very particular scaling needs. On the other hand, they're
not using TURN.
 * Some people on this list are very insistent that we follow ICE
exactly, including off the shelf TURN servers.
 * TURN was invented to solve some problems that are specific to SIP. We
already authenticate with XMPP servers and even have trusted federation,
so shouldn't we take advantage of that? For example, why doesn't
Asterisk implement TURN for it's media relay functionality? A: it
doesn't need to.

So, how do resolve the impasse?

 1) Everyone wants to interop with Google Talk. That might sound shitty
from a standards definition perspective, but let's be practical. :) So,
we need to agree on something that will work for them, or define a
couple of Jingle variations (just like we have with simple UDP and ICE).
 2) The XMPP philosophy is simple client, complex server. This has
served us extremely well in the past and shouldn't be abandoned for
Jingle. To me, that means we should push as far as we can on the client
simplicity route, even if it means deviating somewhat from off the shelf
ICE/TURN.

Does everybody agree with those principles?

Regards,
Matt



More information about the Standards mailing list