Re: Allowing RTCIceServer to contain multiple URLs

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.


>
> A TURN client could lookup the UDP, start trying that  and in parallel go
> get DNS for tcp and test the TCP. If UPD (or TCP) does not work, it takes
> awhile to detect so parallel works out better.
>
> Related to this - for a web scale deployment, I'd do it much like google
> does DNS and have all the TURN servers have the same IP address so it can
> be cached for a long time then use any cast to get to the geographically
> close TURN server.
>

The web server already has a good idea about where you are, so it can
return a list of TURN URIs based on what servers it thinks are closest to
you. This seems simpler than using anycast, as again, it's all under the
control of the web app.