Re: Allowing RTCIceServer to contain multiple URLs

OK, going to summarize this into text for the editors to put into the spec.


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

>
> I could live with that.
>
> On Jun 12, 2013, at 9:26 AM, Justin Uberti <juberti@google.com>
>  wrote:
>
> > 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.
> >
> >
> >
> >
> >
> >
>
>