[Standards] Proposed XMPP Extension: STUNServerDiscovery forJingle
stpeter at jabber.org
Thu Mar 29 03:25:21 UTC 2007
Matt Tucker wrote:
>> 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
> * 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.
Isn't it good to use off-the-shelf software if we can? The sense we get
from people working on NAT traversal is that ICE libraries will be quite
widespread before long.
> * TURN was invented to solve some problems that are specific to SIP.
What are those exactly?
> 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.
I agree that it's good for us to take advantage of aspects of our
technology that are superior. What do you think that means in this context?
> 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).
Well much as I love the Google guys, their service is not set in stone
for all time. Heck, it's still Beta. :)
> 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
Well, we have deviated somewhat from simple client / complex server in
some respects, where it has been necessary. TLS and SASL are a lot more
complex than old jabber:iq:auth to a dedicated SSL port. But there are
libraries to handle that. The same will be true of ICE.
But if we can make the client's job as simple as possible (but not
simpler), then we'll have more adoption.
XMPP Standards Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards