On Fri, May 31, 2013 at 1:44 PM, Eric Rescorla <ekr@rtfm.com> wrote: > > Agree this may not be needed if we can rely on using S-NAPTR to look up >> the TURN server addresses, but is this widely deployed today? >> >> > I agree with Justin that it's highly desirable to be able to have the > semantics that > this is a single TURN server which is reachable via three mechanisms rather > than three separate TURN servers, since I only really want to be connected > to one of them. > > I am not enough of an expert on DNS to know if S-NAPTR is practical here, > but I've certainly heard plenty of complaints about how all but the most > basic > DNS features don't work. Do we have measurements about the accessibility > of S-NAPTR from browser-class endpoints? > > -Ekr > > I personally think S-NAPTR could work here, but there are two trade-offs to consider: S-NAPTR targets are domain names, which means you may incur a round-trip in discovering the associated addresses for the domain names. In some cases, they are pointers to services which also require S-NAPTR look ups (see section 4.3 of RFC 3958 for an example); those may incur two round trips. There are ways to optimize this, but it can incur extra latency. S-NAPTR (and other DDDS approaches) really give you two things: data about what's available and data about the ordering that is preferred by the service owner. While that might come into play here, I have heard a use case for it. Is there one? regards, Ted
Received on Friday, 31 May 2013 21:02:52 UTC