Re: [rtcweb] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11

On Sep 26, 2013 8:27 AM, "Karl Stahl" <karl.stahl@intertex.se> wrote:
>
> Here comes the suggestion I got from my developer that would allow a
network
> provider to offer his TURN server for the WebRTC browser to use. This
would
> require NO new DHCP-options or similar, and NO OS changes (I do realize
> those should be avoided if possible...).
>
> The idea is still, that whoever is responsible for giving a device an IP
> address (the network provider or a LAN administrator) can also announce a
> TURN server for the WebRTC browser to use.
>
> The suggestion is to use RFC6763 (DNS-Based Service Discovery, see chapter
> 11) where the network provider (the owner of the IP address) has set up a
> DNS PTR record for the TURN server in the in-addr.arpa domain.
>
> If the device got IP 173.164.252.149, then make a query for the PTR record
> for:
> _turn._udp.149.252.164.173.in-addr.arpa.
> Then the SRV record would return the actual address to the TURN server
(and
> you may find several for load balancing and failover I guess)
>
> If the device is on a LAN, the IP 173.164.252.149 to query would be the
WAN
> IP you get via STUN in the ICE process. But if the LAN administrator
> provides a local TURN server, then he also should have blocked STUN in the
> firewall, and the browser should query the device's local host address (as
> in the ICE procedure) and the local LAN DNS server should answer the query
> to give the local TURN server address on the LAN.
>
> Shouldn't this work to allow network provider to offer his TURN server
> "automatically and generally"?
>
> And wouldn't this work nicely for mobile devices, whenever the device is
on
> a "WebRTC-ready access" (actually good for everything using ICE), whether
> fixed, WiFi or 3G/4G OTT, you get also a TURN server (and the network
> provider hopefully offers a prioritized pipe there as one usage of this
> mechanism).
>

Does your mobile provider currently do reverse dns for your mobile's real
ip address?

CB

> Not to slow down every call setup by doing this in the ICE process, I
guess
> this could be done when starting the browser and when the device gets a
new
> IP address, to have the TURN server address ready for later use.
>
> /Karl
>
>
> -----Ursprungligt meddelande-----
> Från: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] För
> Markus.Isomaki@nokia.com
> Skickat: den 26 september 2013 14:06
> Till: fluffy@cisco.com; cb.list6@gmail.com
> Kopia: rtcweb@ietf.org
> Ämne: Re: [rtcweb] TURN server address via DHCP, WGLC of
> draft-ietf-rtcweb-use-cases-and-requirements-11
>
> Hi,
>
> Cullen Jennings wrote:
> >
> > I will note that browsers have many ways to learn about HTTP proxies
> > from the network and it seems to me that using some of theses same
> > technique might also be a good way to learn about TURN servers.
> >
>
> I agree. I assume that in enterprises it would be the same people managing
> both of these.
>
> Is there something the IETF can or should do about this, or do we just
> assume it will happen? A new DHCP option is something the IETF could
easily
> do, but I also doubt how usable that would be.
>
> Markus
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>