[Jingle] XEP-0176 - how to find STUN/TURN servers
stpeter at stpeter.im
Wed Apr 8 11:42:13 CDT 2009
On 4/8/09 1:40 AM, Marcus Lundblad wrote:
> tis 2009-04-07 klockan 19:05 -0600 skrev Peter Saint-Andre:
>> On 4/7/09 6:38 PM, Justin Karneges wrote:
>>> Section 9 mentions STUN/TURN, but does not suggest how a client may discover
>>> these services through the XMPP server. In particular, TURN servers may
>>> require credentials and the client will need to know what they are.
>> There are defined methods for discovering STUN/TURN servers using DNS
>> SRV records.
>>> Even XEP-0065 has a way to locate a relay service, through disco.
>> That's because a SOCKS5 Bytestreams proxy communicates over XMPP.
>>> I think we
>>> need a similar approach in XEP-0176 before we can consider it ready.
>> Yes, I've been thinking about that. The method we've defined so far is
>> XEP-0215 (External Service Discovery), which is semantically the same as
>> the method used in Google Talk (jingle-info or whatever they call it).
>> An alternative approach would be to XMPP-enable a TURN server so that
>> you could communicate with it over XMPP, just as you do for a SOCKS5
>> Bytestreams proxy. However, that would require a customized TURN server.
>> But I suppose you could argue that XEP-0215 would require a customized
>> TURN server, too. I think this is an open issue -- not for XEP-0176 but
>> for Jingle in general.
> The way it works using Google's "jingle-info" is that you issue a
> jingle-info get request. In response you get a list of STUN servers (IP
> and port) and a relay discovery address + a relay token.
> The client then issues an HTTP request to that URL setting the token in
> a content header. The HTTP response now contains a list of value-pairs
> for hosts, ports and so on.
What is the relay discovery address? Is that the address of the relay or
some Google-specific service hosted via HTTP?
> I guess we'd need some way for XEP-0215 to enable communicating with a
> TURN server. Though that would probably require a customised TURN
> server. I'm not sure quite how we could implement something like this
> without requiring a custom TURN server, which would sure be a nice
Agreed. But it's also good not to require custom TURN servers (or, if
you want to be generic, media relays) if we can use off-the-shelf
components. TURN already has methods for requesting credentials. The
only reason to tie your TURN credentials into XMPP is to:
1. Take advantage of in-band registration. You could register with TURN
servers / media relays on the network and use those only after
registering (where a media relay might be a friend's computer, as we
discussed in Brussels). If you misuse the relay, it could cancel your
registration (perhaps even informing other relays on the network that
you might be abusing relay services).
2. Use OAuth over XMPP. So for example your XMPP server could request
credentials from the relay on your behalf -- the XMPP server is the
User, you are the Consumer, and the relay is the Protected Resource.
Eventually you would present an access token to the relay over XMPP,
enabling you to access scarce resources on the relay under the auspices
of your XMPP server.
I think we might need something like this, rather than depending on
TURN's built-in credential system, if only to prevent abuse (tying your
usage back to your JID, especially via your server, might improve
accountability). But we need to think about it further.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/jingle/attachments/20090408/8673a006/attachment.bin
More information about the Jingle