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

["Karl Stahl" <[e-mail]>]

I happily withdraw my suggestion to use DHCP to find a network provider
offered TURN server in favor of the DNS-Based Service Discovery method
(inserted last below). The major problem with the DHCP usage was that you
then also have to do something similar for: RA - Router Advertisement - in
IPv6, addition to the IPCP protocol for PPPoE and something for the mobile
OTT channel – wherever DHCP is NOT the method to give you an IP address.

 

Further:

> On Thu, Sep 27, 2013 Justin Uberti wrote:

> Agree. I still think that extending PAC files to include TURN information
is the right way to go.

> PAC files can already be discovered via DHCP or DNS, there is no need to
reinvent this wheel.

 

>>On Thu, Sep 26, 2013 at 4:55 PM, Cullen Jennings (fluffy) <
<mailto:[e-mail]> [e-mail]> wrote:

>>I think we need to give some advise to the browsers vendors on what they
should implement to find turn servers

 

I Googled a bit on PAC and WPAD and saw that a HTTP proxy config JS file can
be picked up through a URL based on the device name. Similar could work for
finding a TURN server on a LAN, but what about the case with a network
provider offered TURN server? The network provider hands out an IP address
and wants to announce a related TURN server address: – Is there a “PAC-way”
to announce it to a device on a LAN (behind a NAT/firewall)? The device must
find such configuration file based on its public IP address (that he can
find using STUN as in the suggestion below).

 

But generally, finding a TURN-server is a network-thing, ICE (or even TURN
not using ICE), not a Web-thing, so for that reason the DNS-Based Service
Discovery method is at a better level. Such method could also be used by SIP
clients (even a Skype client could implement it to benefit from a real-time
path with better quality, if the network provider offers such path through
his TURN server).

 

The DNS-Based Service Discovery method should be easy to implement in a
WebRTC browser (doing complex ICE things anyway). The question is rather how
easy it is for the network provider to provision. Do they all do reverse DNS
like with found with mobile operators TeliaSonera and Tele2 in Sweden? Then
it should not be too difficult.

 

Or is there yet another better method to announce a TURN server address with
the IP address offered?

 

/Karl

 

 

Från: [e-mail] [mailto:[e-mail]] För Bernard
Aboba
Skickat: den 29 september 2013 02:41
Till: Harald Alvestrand
Kopia: [e-mail]
Ämne: Re: [rtcweb] TURN server address via DHCP, WGLC of
draft-ietf-rtcweb-use-cases-and-requirements-11

 

On Sep 26, 2013 8:46 PM, "Harald Alvestrand" <[e-mail]> wrote:
"So far, neither the POSIX standard nor any OS vendor has offered a generic
facility to access information made available in DHCP packets."

 

[BA] The Windows DHCP client API does provide this: 

http://msdn.microsoft.com/en-us/library/windows/desktop/aa363351(v=vs.85).as
px

 

In particular, the SendParams argument to the DhcpRequestParams function can
be used to request a particular parameter (e.g. TURN server address), which
will then be returned in the RecdParams variable.  

 

Nevertheless, I still think that using DHCP to configure the TURN server
address in a browser isn't a good idea.  For one thing, since DHCP is
effectively unsecured, this mechanism could be used by a rogue DHCP server
to force traffic to a rogue turnserver.   Great for surveillance!

 

 

On Sep 27, 2013 1:27 AM, "Karl Stahl" < <mailto:[e-mail]>
[e-mail]> 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).

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