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

Re: Allowing RTCIceServer to contain multiple URLs

From: Justin Uberti <juberti@google.com>
Date: Mon, 3 Jun 2013 16:49:52 -0700
Message-ID: <CAOJ7v-0rWyGeRR-CzRJtR2VQ7fAXKJ0Kx2g3nX2qb_ZebgtFwg@mail.gmail.com>
To: Iñaki Baz Castillo <ibc@aliax.net>
Cc: Eric Rescorla <ekr@rtfm.com>, Ted Hardie <ted.ietf@gmail.com>, Martin Thomson <martin.thomson@gmail.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>, Mallinath Bareddy <mallinath@google.com>
On Mon, Jun 3, 2013 at 3:37 AM, Iñaki Baz Castillo <ibc@aliax.net> wrote:

> 2013/6/1 Justin Uberti <juberti@google.com>:
> > In the best case, the web server can return IP addresses directly to JS
> with
> > the pageload, eliminating any DNS lookup. I think that S-NAPTR for
> > will probably only require a single lookup, but the larger concern is
> that
> > IIRC, DNS on Windows XP does not support S-NAPTR, which would break this
> for
> > a sizable chunk of the Internet population (10%+)
> In some RT protocols, the client does load-balancing and failover
> based on NAPTR/SRV records. For example, a SIP/XMPP client gets the
> SRV records of its domain, chooses one server and, since it does not
> respond, it connects to the next one. That mechanism is builit-in the
> protocol.
> If the WebRTC client performs a NAPTR query and retrieve multiple
> servers, it can try all of them in a *transparent* way for the JS
> application. If instead a single DNS A or IP is given, such a failover
> feature is lost (or should be implemented at JS layer).

Note that we could do the same with regular DNS queries, as long as the
well-known STUN/TURN ports are used. NAPTR is clearly more flexible, but
given the lack of universal support for it, I don't think we can mandate
its use (yet).
Received on Monday, 3 June 2013 23:50:43 UTC

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