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

"Karl Stahl" <karl.stahl@intertex.se> Thu, 26 September 2013 15:27 UTC

Return-Path: <karl.stahl@intertex.se>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C888D11E80D2 for <rtcweb@ietfa.amsl.com>; Thu, 26 Sep 2013 08:27:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.089
X-Spam-Level:
X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oh5VAETItB0U for <rtcweb@ietfa.amsl.com>; Thu, 26 Sep 2013 08:27:22 -0700 (PDT)
Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.161]) by ietfa.amsl.com (Postfix) with ESMTP id C259E11E8109 for <rtcweb@ietf.org>; Thu, 26 Sep 2013 08:27:20 -0700 (PDT)
Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201309261727165400; Thu, 26 Sep 2013 17:27:16 +0200
From: Karl Stahl <karl.stahl@intertex.se>
To: Markus.Isomaki@nokia.com, fluffy@cisco.com, cb.list6@gmail.com
References: <C5E08FE080ACFD4DAE31E4BDBF944EB11667BBA0@xmb-aln-x02.cisco.com> <523c6d3d.c9d1440a.3b96.7499SMTPIN_ADDED_BROKEN@mx.google.com> <CAD6AjGRXr5kPRQdN+4jkgXHciN3NE7HiRmsb7kaYuzwHEPa7ZA@mail.gmail.com> <C5E08FE080ACFD4DAE31E4BDBF944EB1166CC702@xmb-aln-x02.cisco.com> <E44893DD4E290745BB608EB23FDDB7620A0CDABB@008-AM1MPN1-042.mgdnok.nokia.com>
In-Reply-To: <E44893DD4E290745BB608EB23FDDB7620A0CDABB@008-AM1MPN1-042.mgdnok.nokia.com>
Date: Thu, 26 Sep 2013 17:27:16 +0200
Message-ID: <0d7a01cebacc$e20a65b0$a61f3110$@stahl>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AQHOuH4XwliCL5K4nkCG0uCnhbf1JJnWFfMAgAHIA1CAABYNkA==
Content-Language: sv
Cc: rtcweb@ietf.org, draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org
Subject: Re: [rtcweb] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Sep 2013 15:27:26 -0000

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


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