- From: Cullen Jennings (fluffy) <fluffy@cisco.com>
- Date: Fri, 7 Jun 2013 11:11:04 +0000
- To: Eric Rescorla <ekr@rtfm.com>
- CC: Justin Uberti <juberti@google.com>, Martin Thomson <martin.thomson@gmail.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On Jun 7, 2013, at 11:55 AM, Eric Rescorla <ekr@rtfm.com> wrote: > > > > On Thu, Jun 6, 2013 at 9:42 PM, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote: > > On Jun 6, 2013, at 10:30 PM, Justin Uberti <juberti@google.com> wrote: > > > The sections you are pointing to discuss the use of SRV to perform a lookup of a STUN or TURN server for a particular domain. How did you see this working with a TURN URI? > > > > That is, if the TURN URI specifies turn:foo.example.com, are you expecting the browser to do a SRV lookup of _turn._udp.foo.example.com, _turn._tcp.foo.example.com, and _turns._tcp.foo.example.com - each of which will return a DNS name that will require another query to obtain the IP address? > > > > > > Yes. Pretty much. Keep in mind the server has no idea which will works so you are going to need to try the transports to see what works. > > A TURN client could lookup the UDP, start trying that and in parallel go get DNS for tcp and test the TCP. If UPD (or TCP) does not work, it takes awhile to detect so parallel works out better. > > Do we have measurements on the SRV success rate from typical browser clients? Any reason to think it might be less than say A records? > > > Related to this - for a web scale deployment, I'd do it much like google does DNS and have all the TURN servers have the same IP address so it can be cached for a long time then use any cast to get to the geographically close TURN server. > > Hmm... Anycast really isn't guaranteed to be stable over this kind of time > scale. Fair enough - that's always the issue brought up. Actually anycast isn't guaranteed to be stable over any time so very implementation dependent what happens. > > -Ekr > >
Received on Friday, 7 June 2013 11:12:09 UTC