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

"Karl Stahl" <karl.stahl@intertex.se> Mon, 07 October 2013 12:21 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 354E021E81C1 for <rtcweb@ietfa.amsl.com>; Mon, 7 Oct 2013 05:21:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.966
X-Spam-Level:
X-Spam-Status: No, score=-1.966 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_LOW=-1, URI_HEX=0.368]
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 tVQ2XM+XA56z for <rtcweb@ietfa.amsl.com>; Mon, 7 Oct 2013 05:21:13 -0700 (PDT)
Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.161]) by ietfa.amsl.com (Postfix) with ESMTP id E6E8E21E8190 for <rtcweb@ietf.org>; Mon, 7 Oct 2013 05:21:10 -0700 (PDT)
Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201310071421064219; Mon, 07 Oct 2013 14:21:06 +0200
From: Karl Stahl <karl.stahl@intertex.se>
To: 'Saverio Vardaro' <saverio.vardaro@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> <52445257.8581700a.36b0.fffff687SMTPIN_ADDED_BROKEN@mx.google.com> <CAD6AjGTZyCRd9QKniO1D99tSQQddyipKKdqPj2zVnzxB1-c5Kg@mail.gmail.com> <5245c4af.8908420a.33f6.ffff8025SMTPIN_ADDED_BROKEN@mx.google.com> <CAGQXTApP1W3SK_U=qRH+PK=7o06WVysOe5rfCzSFEJTZMFJmkA@mail.gmail.com>
In-Reply-To: <CAGQXTApP1W3SK_U=qRH+PK=7o06WVysOe5rfCzSFEJTZMFJmkA@mail.gmail.com>
Date: Mon, 07 Oct 2013 14:21:08 +0200
Message-ID: <044101cec357$b3b556a0$1b2003e0$@stahl>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0442_01CEC368.773E26A0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac6+v3pJAKiiLD3XSiO7/NAQdY11QAElaE9w
Content-Language: sv
Cc: fluffy@cisco.com, 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: Mon, 07 Oct 2013 12:21:19 -0000

We checked some more mobile service providers in US and Japan (Softbank) and
they all did reverse DNS for the real IP address at the OTT channel.

 

US: Charter Communications, Broadband: Hostname:
66-189-44-147.dhcp.oxfr.ma.charter.com 

US: Verizon Wireless, Wireless Broadband: Hostname:
179.sub-174-252-35.myvzw.com

Japan (Softbank): ASAHI Net,Inc.: Hostname: k185241.ppp.asahi-net.or.jp

Sweden (Tele2/Comviq): Hostname: m90-130-225-160.cust.tele2.se

Sweden: Telia Sonera AB, Wireless Broadband: Hostname:
host-95-199-20-150.mobileonline.telia.com

Sweden: Tele2 SWlPnet, Tele2 Mobil, wireless Broadband: Hostname:
m5-243-149-119.cust.tele2.se

Sweden: Telenor Sverige AB, Wireless Broadband: Hostname:
c-5eeaaa41-74736162.cust.telenor.se

 

/Karl

 

Från: Saverio Vardaro [mailto:saverio.vardaro@gmail.com] 
Skickat: den 1 oktober 2013 18:01
Till: Karl Stahl
Kopia: cb.list6; fluffy@cisco.com; rtcweb@ietf.org;
draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org
Ämne: Re: [rtcweb] TURN server address via DHCP, WGLC of
draft-ietf-rtcweb-use-cases-and-requirements-11

 

 

 

On Fri, Sep 27, 2013 at 7:47 PM, Karl Stahl <karl.stahl@intertex.se> wrote:

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

>CB

Good question and the answer is good: Yes

We just checked both major 3G mobile operators TeleaSonera and Tele2 in
Sweden.

E.g. just surfing  to http://whatismyipaddress.com 

(which tells me it is TeliaSonera, Wireless Broadband)

Then clicking the “Additional IP Details” button, I get the PTR record:

host-95-199-196-65.mobileonline.telia.com

Tele2 gave: m83-186-15-99.cust.tele2.se

 

So, obviously mobile providers have ways of provisioning these kind of
things in DNS.

 

How does it look in other places of the world?

 

[SV] This is NOT the case for Vodafone Italy

 

/Karl

 

 

Från: cb.list6 [mailto:cb.list6@gmail.com] 
Skickat: den 27 september 2013 01:06
Till: Karl Stahl
Kopia: fluffy@cisco.com; rtcweb@ietf.org;
draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org;
Markus.Isomaki@nokia.com
Ämne: Re: SV: [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
>


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb