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

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

-----Ursprungligt meddelande-----
Från: Cullen Jennings (fluffy) [mailto:[e-mail]] 
Skickat: den 25 september 2013 06:56
Till: cb.list6
Kopia: Karl Stahl; <[e-mail]>
Ämne: Re: [rtcweb] TURN server address via DHCP, WGLC of
draft-ietf-rtcweb-use-cases-and-requirements-11


> On desktop OS, it is very hard for an application like a browser to learn
any information that was passed via DHCP to the host. This has long been a
problem for things like geopriv. 
[Karl] A WebRTC browser must be far beyond "a simple application". How can
it otherwise see and hear us, send RTP over UDP, do ICE and other advanced
stuff? It must already hook deep into the OS, so that in itself cannot be a
problem if the OS would know about such a handy thing as a network provided
TURN server...

[Karl] The problem is how will Network Provider can tell the OS about the
TURN server he provides together with his access: One of our developers
actually came up with a way of doing that WITHOUT my "provided via DHCP (and
maybe RA - Router Advertisement - for IPv6, and the OTT channel in mobiles
have their own method I’ve been told)"! I'll come back tomorrow to explain
(asked him to write a few line so I can convey correctly).

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


On Sep 23, 2013, at 9:58 AM, cb.list6 <[e-mail]> wrote:

> 
> On Sep 20, 2013 8:43 AM, "Karl Stahl" <[e-mail]> wrote:
> >
> > For NAT/Firewall traversal WebRTC uses ICE, where the browser today 
> > gets the TURN server address from the web application, or gets it 
> > configured by a LAN admin via an “admin policy template”.
> >
> > However, there is a need (motivations below) for the TURN server 
> > address to be provided via DHCP (and maybe RA - Router Advertisement 
> > - for IPv6, and the OTT channel in mobiles have their own method 
> > I’ve been told). Simply put, just as you often get your IP-address, 
> > DNS address, etc. automatically from the network access, you should also
get the TURN server address.
> >
> > I suggest the following is added to the end of use case (which today 
> > is about multiple TURN servers) 3.2.4.  Simple Video Communication 
> > Service, global service provider 3.2.4.1.  Description ...
> > "A network service provider must be able to automatically supply a 
> > TURN server addresses to the browser when accessing a network. The 
> > address may come via DHCP or a similar mechanism (maybe RA - Router 
> > Advertisement - for IPv6, an addition to the IPCP protocol like 
> > RFC1877 for PPPoE, or whatever method the mobile OTT channels use). 
> > The mechanism should be similar to automatically getting the 
> > IP-address, DNS address, etc.. and need extensions to current
recommendations/standards.
> >
> > There are several reasons for a network service provider to supply a 
> > TURN server as part of his offered access:
> > - to keep media paths short, specifically not sending media outside 
> > its own network to some distant application provided TURN server
> > - to support mobility, i.e. you may want to move from a LAN with a 
> > configured TURN server to accessing via WiFi or 3G/4G OTT channels
> 
> I have not read the draft but would like to make it clear that no 2g/3g/4g
provider uses dhcp over the mobile network so this dhcp solution would not
apply.
> 
> CB
> 
> > - to offer a media path with better quality (than best effort data
traffic).
> > Getting “WebRTC-ready” access and we look forward to telepresence 
> > for everyone.
> >
> > An enterprise network that want to keep a restrictive firewall not 
> > allowing UDP traffic, could provide a real-time path using a TURN 
> > server paralleling the firewall, instead of tunneling RTP through 
> > always open http or https ports resulting in RTP media over TCP – 
> > with severe quality problems from TCP retransmissions of dropped 
> > packets. The TURN server address is most easily provided in the same 
> > way as the IP address and DNS address. (That would also put the 
> > right party in control – The network provider decides what is 
> > allowed on his network.)
> >
> > This browser should select which available TURN server address to 
> > use in the following priority order, where ICE could be used to try
several:
> >
> > 1) TURN server address configured in the browser by the user 
> > (special cases, normally not used)
> > 2) TURN server address configured by the network administrator via 
> > an “admin policy template”
> > 3) TURN server address supplied by DHCP or similar automatic network 
> > method
> > 4) TURN server address being supplied by the web application"
> >
> > Two new requirements can be extracted:
> > "   ----------------------------------------------------------------
> >    F40     The browser must support retrieving TURN server addresses via
> > DHCP or a similar mechanism (maybe RA - Router Advertisement - for 
> > IPv6, an addition to the IPCP protocol like RFC1877 for PPPoE, or 
> > whatever method the mobile OTT channels use). The mechanism should 
> > be similar to automatically getting the IP-address, DNS address, etc..
> >    ----------------------------------------------------------------
> >    F42     This browser should select which available TURN server
address to
> > use in the following priority order, where ICE could be used to try
several:
> >
> > 1) TURN server address configured in the browser by the user 
> > (special cases, normally not used)
> > 2) TURN server address configured by the network administrator via 
> > an “admin policy template”
> > 3) TURN server address supplied by DHCP or similar automatic network 
> > method
> > 4) TURN server address being supplied by the web application 
> > ----------------------------------------------------------------"
> >
> > I suppose this also will add to:
> > 5.  IANA Considerations
> >    TBD
> >
> > /Karl
> >
> >
> > -----Ursprungligt meddelande-----
> > Från: [e-mail] [mailto:[e-mail]] För 
> > Cullen Jennings (fluffy)
> > Skickat: den 4 september 2013 18:24
> > Till: [e-mail]
> > Ämne: [rtcweb] WGLC of 
> > draft-ietf-rtcweb-use-cases-and-requirements-11
> >
> >
> > We would like to start a working group last call of 
> > draft-ietf-rtcweb-use-cases-and-requirements-11.
> >
> > Please send comments by the end of the day on September 21.
> >
> > Thank you,
> >
> > The chairs ….
> >
> >
> >
> >
> > _______________________________________________
> > rtcweb mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >
> > _______________________________________________
> > rtcweb mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/rtcweb