Re: Allowing RTCIceServer to contain multiple URLs

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.
> 
> 
> 
> 
> 
>

Received on Wednesday, 12 June 2013 06:25:28 UTC