Subject: [rtcweb] Interim agenda and network provided TURN server, draft-patil-tram-turn-serv-disc-01.txt

From: "Karl Stahl" <[email-masked]>
Date: Sun, 18 May 2014 14:50:25 +0200

Is the usage of auto discovered TURN servers by the WebRTC browser 
written into any rtcweb draft or is that to be done? 

I have only seen some enterprise scenario described in the informational 
draft-ietf-rtcweb-use-cases-and-requirements-14.txt and its requirement:  
F19     The browser must be able to use several STUN and TURN servers

Will this be discussed during the Interim meeting now? When?

Below are pointers and some comments to the 
draft-patil-tram-turn-serv-disc-01.txt for the discovery of enterprise 
and ISP provided TURN servers.

/Karl

-----Ursprungligt meddelande-----
Från: tram [mailto:[email-masked]] För Karl Stahl
Skickat: den 18 maj 2014 14:44
Till: 'Prashanth Patil (praspati)'; [email-masked]; 'Simon Perreault'
Ämne: Re: [tram] New Version Notification for
draft-patil-tram-turn-serv-disc-01.txt

I browsed through this document and to me it looks mature enough to be
pushed forward (hopefully soon) to get an IANA anycast address etc., so
these things can be put into current WebRTC browsers. As we know, many
enterprises cannot use WebRTC at all today due to their restrictive firewall
policies - they need a TURN server on their LAN, discovered and used by the
WebRTC browsers to even begin using WebRTC.

However, I raised a few questions and some suggestions
http://www.ietf.org/mail-archive/web/tram/current/msg00480.html
at the end of the previous version of this draft that never became discussed
and remain:

A) Under 8.2 there is a suggested way to assure that the TURN server
returned by the anycast method, is provided by the network provider (and not
some far away TURN server that should not be trusted to use without
authentication): "... can set an IP TTL on their TURN requests that limits
how far they can travel into the public Internet."

I suggest that this TTL limitation is specified (e.g. Don't look further
than 3 steps - local firewall + max 2 ISP routers) and brought into section
"5. Discovery using Anycast" of the draft.

B) Shall we really have more than one method? If the Anycast method can be
used by everyone, why then also have DHCP and now a two more methods?

I assume you intend that all webrtc browsers implement and can use all
methods? Or? (If a service provider e.g. deploys DHCP discovered TURN
servers, but some webrtc browser in some operating system don't find/cannot
use the TURN server, it would be bad.)

In previous discussions, there were some fears that DHCP options are not
available in some common OSs. If so, I think the DHCP method should be
skipped. 

Also, if the other methods (other than anycast) may fail, why have them? 
Are they better to deploy and provision for network service providers?

And will webrtc browsers implement all these methods?

Do we have input/feedback on these questions?

Should the "connect speed factor" not also be considered? Even though the
auto discovery can be done in advance of a call, we should consider the
mobility use case. With a mobile client changing network, LAN/LTE/public
WiFi etc., we want to get up and run as soon as possible, so the auto
discovery of a new TURN server should not be a tedious process

And should the quick anycast auto discovery not be the first to be
tried/used (which it is not now in the draft)?

C) I noticed that referenced I-D.ietf-geopriv-res-gw-lis-discovery
is now RFC7216.

/Karl

-----Ursprungligt meddelande-----
Från: tram [mailto:[email-masked]] För Prashanth Patil (praspati)
Skickat: den 2 maj 2014 12:02
Till: [email-masked]
Ämne: [tram] FW: New Version Notification for
draft-patil-tram-turn-serv-disc-01.txt

A new revision of the TURN server discovery draft has been published.
Notable updates :

* 300 (Try Alternate) response for anycast.
* Mechanism described in draft-kist-alto-3pdisc i.e. using the clients own
address to populate the DNS reverse zone (i.e., in-addr.arpa or ip6.arpa)
with appropriate NAPTR records pointing to the TURN server.
* Learning domain names from own identity.

-Prashanth

On 5/2/14 3:25 PM, "[email-masked]" <[email-masked]>
wrote:

>
>A new version of I-D, draft-patil-tram-turn-serv-disc-01.txt
>has been successfully submitted by Prashanth Patil and posted to the 
>IETF repository.
>
>Name:		draft-patil-tram-turn-serv-disc
>Revision:	01
>Title:		TURN Server Auto Discovery
>Document date:	2014-05-02
>Group:		Individual Submission
>Pages:		11
>URL:            
>http://www.ietf.org/internet-drafts/draft-patil-tram-turn-serv-disc-01.txt
>Status:         
>https://datatracker.ietf.org/doc/draft-patil-tram-turn-serv-disc/
>Htmlized:       
>http://tools.ietf.org/html/draft-patil-tram-turn-serv-disc-01
>Diff:           
>http://www.ietf.org/rfcdiff?url2=draft-patil-tram-turn-serv-disc-01
>
>Abstract:
>   Current Traversal Using Relays around NAT (TURN) server discovery
>   mechanisms are relatively static and limited to explicit
>   configuration.  These are usually under the administrative control of
>   the application or TURN service provider, and not the enterprise or
>   the ISP, the network in which the client is located.  Enterprises and
>   ISPs wishing to provide their own TURN servers need auto discovery
>   mechanisms that a TURN client could use with no or minimal
>   configuration.  This document describes two such mechanisms for TURN
>   server discovery.
>
>                  
>        
>
>
>Please note that it may take a couple of minutes from the time of 
>submission until the htmlized version and diff are available at 
>tools.ietf.org.
>
>The IETF Secretariat
>

_______________________________________________
tram mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tram

_______________________________________________
tram mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tram

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Sun, 18 May 2014 13:33:20 +0000

> written into any rtcweb draft or is that to be done? 

I don’t think so. There has been some discussion of if a pac file type approach could be used much like how the HTTP proxy is discovered.

---

From: "Karl Stahl" <[email-masked]>
Date: Sun, 18 May 2014 16:49:25 +0200

That would only be for local/static enterprise usage, not a turn server that
a network provider (enterprise or ISP) can provision and offer for anyone
using that access. The auto discovery is required for mobile devices
accessing many networks and for other reasons, that pac files cannot fulfil.

/Karl

-----Ursprungligt meddelande-----
Från: Cullen Jennings (fluffy) [mailto:[email-masked]] 
Skickat: den 18 maj 2014 15:33
Till: Karl Stahl
Kopia: [email-masked]
Ämne: Re: [rtcweb] Interim agenda and network provided TURN server,

> written into any rtcweb draft or is that to be done?

I don’t think so. There has been some discussion of if a pac file type
approach could be used much like how the HTTP proxy is discovered.

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 19 May 2014 01:12:23 +0000

We have it documented as a requirement in draft-ietf-rtcweb-use-cases-and-requirements which states:

   F20     The browser must support the use of STUN and TURN
           servers that are supplied by entities other than
           the web application (i.e. the network provider).

The task of documenting the solution to this has been delegated to TRAM which has a milestone for this.

Probably there should be a RTCWEB draft which references the solution to this when there is one and probably the best candidate for this is draft-ietf-rtcweb-transports so maybe this should be listed as an open issue in -transports-.

Regards
Andy

> -----Original Message-----
> From: rtcweb [mailto:[email-masked]] On Behalf Of Cullen
> Jennings (fluffy)
> Sent: 18 May 2014 14:33
> To: Karl Stahl
> Cc: [email-masked]
> Subject: Re: [rtcweb] Interim agenda and network provided TURN server,
> I don't think so. There has been some discussion of if a pac file type
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Martin Thomson <[email-masked]>
Date: Sun, 18 May 2014 19:32:13 -0700

> I don’t think so. There has been some discussion of if a pac file type approach could be used much like how the HTTP proxy is discovered.

Firefox has a pref for a STUN server.  That is used if you don't
supply any STUN or TURN servers of your own.  Users can add their own
TURN server here.

The idea of autodiscovery is interesting, but it's still early days.

---

From: "Karl Stahl" <[email-masked]>
Date: Mon, 19 May 2014 09:07:50 +0200

The need and methods for discovering a network provided (enterprise and ISP) turn server was discussed in september-october http://www.ietf.org/mail-archive/web/rtcweb/current/msg09128.html 
and is now being worked out in the tram draft in the subject.

We need to get such turn servers used by the webrtc browsers for many reasons, 
http://www.ietf.org/mail-archive/web/tram/current/msg00132.html 
E.g. many enterprises cannot use WebRTC at all today due to their restrictive firewall policies - they need a TURN server with one LAN-interface, discovered and used by the WebRTC browsers to even begin using WebRTC.

The tram-draft method of having an anycast address for such turn-server seems quick and easy to implement in the browsers, so we get something working - but there is no IANA assigned anycast address for that yet...

The rtcweb-transports draft may be the place to put such usage in.

/Karl

-----Ursprungligt meddelande-----
Från: Martin Thomson [mailto:[email-masked]] 
Skickat: den 19 maj 2014 04:32
Till: Cullen Jennings (fluffy)
Kopia: Karl Stahl; [email-masked]
Ämne: Re: [rtcweb] Interim agenda and network provided TURN server, draft-patil-tram-turn-serv-disc-01.txt

> I don’t think so. There has been some discussion of if a pac file type approach could be used much like how the HTTP proxy is discovered.

Firefox has a pref for a STUN server.  That is used if you don't supply any STUN or TURN servers of your own.  Users can add their own TURN server here.