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

["Cullen Jennings (fluffy)" <[e-mail]>]

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. 

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