W3C home > Mailing lists > Public > public-webrtc@w3.org > May 2013

Re: Allowing RTCIceServer to contain multiple URLs

From: Ted Hardie <ted.ietf@gmail.com>
Date: Fri, 31 May 2013 14:02:25 -0700
Message-ID: <CA+9kkMAaA4vue9Lr7wUQYyb24scBTbkFGB6vFv2HwcfcvYoTZA@mail.gmail.com>
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>, Mallinath Bareddy <mallinath@google.com>
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

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?


Received on Friday, 31 May 2013 21:02:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:43 UTC