Re: Allowing RTCIceServer to contain multiple URLs

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 Saturday, 8 June 2013 03:57:32 UTC