[Standards] Proposed XMPP Extension: STUNServerDiscovery forJingle

Peter Saint-Andre stpeter at jabber.org
Thu Mar 29 03:25:21 UTC 2007

Matt Tucker wrote:
> 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.

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?

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

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.


Peter Saint-Andre
XMPP Standards Foundation

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070328/7d6f0c35/attachment.bin>

More information about the Standards mailing list