-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/10/09 9:13 PM, Justin Karneges wrote: > On Thursday 10 September 2009 19:15:24 Peter Saint-Andre wrote: >> On 8/25/09 3:47 AM, Evgeniy Khramtsov wrote: >>> Evgeniy Khramtsov wrote: >>>> Hello. >>>> >>>> I'm thinking of XEP-0215 implementation. In fact, the XEP is very >>>> simple to implement (at least on server), but that leads to >>>> configuration overkill. I imagine a system administrator maintaining a >>>> server with N nodes in a cluster and H virtual hosts. He wants to >>>> configure a stun, stuns, turn and turns server in external discovery. >>>> In that case he need to create N*3*H*3*H records in the configuration >>>> file: a stun and turn takes 3 sections per virtual host (udp, tcp and >>>> tls) each and requires to configure it on every node. If N=2 and H=2 >>>> (a cluster of 2 nodes and 2 virtual hosts) he needs to create 72 >>>> records! Of course a server software may provide a technique to reduce >>>> the overhead, but that may cause a configuration file complexity. >>>> >>>> Personally, I'm interesting in a short-term credentials allocation for >>>> a TURN server. I think DNS is the right place to discover stun/turn >>>> services since corresponding specifications provide SRV records for >>>> that. >> I agree. That's the whole point of SRV records, after all! Right now >> XEP-0215 is strictly a fallback, as is the jingleinfo protocol used in >> Google Talk: >> >> http://code.google.com/apis/talk/jep_extensions/jingleinfo.html > > If we decide to use SRV for STUN/TURN, we'll need to specify somewhere (in a > XEP?) which domain we're supposed to do the standard SRV lookup on. Is it > the JID domain or the connect host, for example? > > Also, can we think of any situation where SRV might be too restrictive? > Especially if we choose to use the JID domain, then the records could end up > being "top-level", sibling to XMPP: > _xmpp-client._tcp.cisco.com > _turn._udp.cisco.com
I think that's fine, because the SRV results will point you to the right machine(s).... $ dig +short -t SRV _xmpp-client._tcp.cisco.com 0 1 5222 isj3cmx.webexconnect.com. (actual result! :) $ dig +short -t SRV _turn._udp.cisco.com 0 1 9999 turn123.cisco.com. (not actual result) > This may cause overlap with another service that needs to reference TURN from > the same place, based on the same domain, such as SIP. And maybe this is > fine, and SIP and XMPP could share TURN credentials, but I just wanted to > make sure this was brought up. Yes, I think that SIP and XMPP can share TURN credentials. Why not? From the perspective of the TURN relay there is no difference between the two (as far as I can see). > I personally like the idea of using an iq to obtain the TURN host, as it adds > a nice layer of indirection for XMPP. But I'm not a network admin and don't > know if this is really needed or desired. When in doubt, add another layer of indirection? :) Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqpwqUACgkQNL8k5A2w/vxHhQCgrqMHJSEyYJh27G+W4CFpjoG9 xhIAoOglpvsYeS8FBC9qdvaCqxE75KRc =VYUl -----END PGP SIGNATURE-----
