Re: Allowing RTCIceServer to contain multiple URLs

I looked over RFC 5928, and I see what you are saying - depending on what
you fill in in the TURN URI, you get either no resolution (IP:port), A
lookup (hostname:port), SRV lookup (hostname:transport), S-NAPTR lookup
(hostname only).

So, winding back to the original proposal:
- RTCIceConfiguration currently contains a list of RTCIceServers (allowing
for multiple different STUN/TURN servers to be specified, and all of them
used).
- RTCIceServer currently contains |uri|, |username|, and |password| fields.
- If you want to use S-NAPTR to look up the ports for UDP/TURN/TLS for a
given TURN server, you supply "turn:<hostname>" in the |uri| field, as
indicated by RFC 5928. Same for SRV lookup.
- However, if you want to specify the ports directly in JS, we need a way
to pass in multiple URIs for a single RTCIceServer.
*- Therefore, we should change RTCIceServer to have a |uris| field, which
would be a list of STUN/TURN URIs that correspond to a *single* STUN/TURN
server, in preference order.*
- Aside from this syntax change, all other RTCIceServer usages are
unaffected (e.g. you still put multiple RTCIceServers into a
RTCIceConfiguration to support the multiple server case).


On Fri, Jun 7, 2013 at 8:56 PM, Cullen Jennings (fluffy)
<fluffy@cisco.com>wrote:

>
> On Jun 8, 2013, at 3:14 AM, Justin Uberti <juberti@google.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.
> >
> > Of course. But the thing to also keep in mind is that the server can
> also supply up-to-date information for each client, which is a lot
> different than the historical SIP client model, where the names would have
> to be baked into the binary. So some of the rationale for using SRV doesn't
> really apply here.
> >
> > It seems much easier for the web server to send down a list of DNS names
> (or IPs, if desired) for all the transports for a particular TURN server,
> and then the client can try them all in parallel, stopping immediately if
> UDP is found to work.
> >
> > This only requires a single DNS lookup (assuming the same TURN host is
> used for all transports), compared to 2 for the SRV approach. It also lets
> the web application do load-balancing, instead of pushing this onto the DNS
> rotor.
> >
>
> Sure - and go one step further and just send the IP address in the TURN
> URN if the web server can control all that. I thought that was the point of
> the current TURN URN design such that you can have just a domain and the
> discover of protocols happens, or you have a URN that locks down the
> protocol, or you have a URN that is an IP with no use of DNS. Seems like
> different folks will want different variants of that.
>
> So I don't feel strongly about any of the design here but it seemed like
> it pretty much did what was needed. The only issues seems to be if you find
> more than one TURN server, does the browser include candidates for just the
> first TURN server to work or does it include candidates for all of them. I
> don't care much one way or the other but if one really cared seems like
> adding a SRV style priority to each TURN URN would solve the problem in a
> very flexible way and not change the code much from existing SRV code.
>
>
>
>
>
>