[Standards] Proposed XMPP Extension: STUNServerDiscovery forJingle

Matt Tucker matt at jivesoftware.com
Wed Mar 28 15:18:43 UTC 2007


> This doesn't mean the secret needs to be shared on an ongoing 
> basis, the XMPP server can have something like a private key 
> and sign a timestamp with it, creating a ticket which the 
> relay server can verify offline using a public key, without 
> further reference to the XMPP server. My understanding is 
> that the Google relay stuff works along these lines.
> >> 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.
> > 
> > Off-the-shelf is a plus. We don't want to be off in our little XMPP 
> > ghetto here.
> +1 :D

I don't quite get it. You just described a relay server mechanism that's
custom and then added a +1 comment on making things "off the shelf". :)
What I'm seeing:

 * Google doesn't use TURN.
 * TURN servers don't exist in general, certainly nothing "off the
 * I can't find anything in the TURN spec about this advanced shared key
logic (expiring shared keys), so I'm not sure how an off the shelf
server could ever work anyway.
 * TURN doesn't cover the HTTPS relay trick that Google uses, which I
think may be worth standardizing.

None of this is a problem for me at all -- we just need to agree on a
simple relay mechanism that works well and document it.

I keep coming back to a point made a few weeks back -- if everything
about Jingle is exactly the same as SIP, there is exactly zero benefit
to using Jingle instead of SIP.


More information about the Standards mailing list