Re: Allowing RTCIceServer to contain multiple URLs

On Wed, Jun 5, 2013 at 11:21 PM, Cullen Jennings (fluffy)
<fluffy@cisco.com>wrote:

>
> On Jun 1, 2013, at 3:44 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> > On Wed, Apr 24, 2013 at 9:34 PM, Justin Uberti <juberti@google.com>
> wrote:
> > I wasn't suggesting that you couldn't have multiple RTCIceServers -
> clearly that's something we still want to support.
> >
> > The idea was mainly to indicate a specific TURN server could be
> reachable via different protocols - while that can be accomplished via
> multiple RTCIceServers, it might not be desirable to try to use all
> protocols at once and allocate 3 TURN candidates (e.g. for UDP, TCP, and
> TLS). If there were multiple transports available for a single TURN server,
> TCP and TLS could be ignored if UDP worked (i.e. and only a single
> candidate would be allocated).
> >
> > 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.
>
> +1
>
> But have a read of section 6.1 of http://tools.ietf.org/html/rfc5766
>
> and
>
> http://tools.ietf.org/html/rfc5389#page-21
>
> I thought TURN already did what you needed (and did not rely on NAPTR or
> S-NAPTR)
>
>
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?



> >
> > 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
> >
> >
> >
> >
> > On Wed, Apr 24, 2013 at 10:50 AM, Martin Thomson <
> martin.thomson@gmail.com> wrote:
> > On 23 April 2013 23:06, Justin Uberti <juberti@google.com> wrote:
> > > So to do this using the existing RTCIceServer syntax, one must create
> > > separate RTCIceServer objects for each URI, all with the same
> credentials.
> > > It seems like it would be cleaner to allow a list of URIs to be
> supplied in
> > > a RTCIceServer, which would all share the same credentials. To achieve
> this,
> > > we could simply change the current .url property from a DOMString to a
> list,
> > > or add a new .urls property that is a list of DOMStrings.
> >
> > > Any objections?
> >
> > Yeah, what Cullen said, plus: if you have multiple URIs with the same
> > credentials, make multiple RTCIceServers.  It's not especially hard:
> >
> > var iceServers = stunServers.concat(turnUris.map(function(turnUri) {
> > return { url: turnUri, credential: cred, username: user }; }));
> >
> >
>
>