[Standards] Proposed XMPP Extension: STUNServerDiscovery forJingle
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