[Standards] Proposed XMPP Extension: STUNServerDiscovery forJingle
robert.mcqueen at collabora.co.uk
Wed Mar 28 17:10:14 UTC 2007
Matt Tucker wrote:
> 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". :)
No, the interaction between the TURN server and the XMPP server isn't
specified. The client can get auth credentials from the XMPP server and
present them to the TURN server without knowing their significance. If
the XMPP server and the TURN server are doing this public/private key
thing, that's an implementation detail.
> What I'm seeing:
> * Google doesn't use TURN.
I imagine that provided the standardised solution meets their needs,
they'll adopt it in future. What they're using ATM certainly puts
relaying instructions in STUN-format packets to the allocated relay
ports, so it's not far off TURN in that respect.
> * TURN servers don't exist in general, certainly nothing "off the
Well, this is predicated on them existing in future. If we standardise
on it, Google are likely to provide an implementation, as are we, and as
are other people who are deploying SIP.
> * 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.
If you're using an off the shelf server with it's own authentication
backend, then it's your perogative to hook it up to your XMPP server. If
Google wants to make use of more exciting shared keys and such, they can
simply make a more clever XMPP server and relay server, as they've done.
The key thing is that we don't preclude either.
> * TURN doesn't cover the HTTPS relay trick that Google uses, which I
> think may be worth standardizing.
Right, I agree. But that's an extension in how clients speak to their
servers which we can benefit from if we choose, but we can do that
without harming the reusability of SIP-originated libraries and
infrastructure if we use standard TURN in the other cases.
> 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.
Not at all, we have a lot of benefits in XMPP over SIP, such as strong
authentication, strong privacy, presence, advanced messaging, simple
routing of signalling, direct peer to peer media working in more cases
due to adoption of ICE, etc. Essentially these are the all of the
reasons that make Jingle superior to currently deployed SIP, and hence
the reason it exists at all.
I think it's possible for us to benefit from all of these *and* remain
compatible with SIP on the wire (which is all that I'm aiming for in the
end) so that you can re-use SIP client and server infrastructure if you
choose, and SIP servers can gateway onto XMPP without much effort, both
of which I think will help the adoption of Jingle a great deal.
If being interoperable with SIP is an optional bolt on, and deploying
your known-working SIP infrastructure isn't guaranteed to let you talk
to another Jingle client, I think that will be very harmful to us.
More information about the Standards