[Standards] Proposed XMPP Extension: STUNServerDiscovery forJingle
scottlu at google.com
Wed Mar 28 17:24:51 UTC 2007
On Mar 28, 2007 10:10 AM, Robert McQueen <robert.mcqueen at collabora.co.uk> wrote:
> Matt Tucker wrote:
> > Rob,
> > 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.
We would like to standardize on TURN as well once it is mature. We're
not trying to propose an alternate relaying standard. What we're using
now is close to TURN. We will want to continue to use the port 443
trick, so that would be an extension.
Re: the discussion around allocating directly vs. using xmpp - it's
simple either way from a client point of view. The direct approach
allows for flexibility in the service implementation and that's
> > * TURN servers don't exist in general, certainly nothing "off the
> > shelf".
> 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.
The important thing is that clients have one way to allocate relay
candidates. As long as this is maintained, service providers can do
what they want when it comes to implementation.
More information about the Standards