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

On Sep 20, 2013 8:43 AM, "Karl Stahl" <karl.stahl@intertex.se> 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: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] För Cullen
> Jennings (fluffy)
> Skickat: den 4 september 2013 18:24
> Till: rtcweb@ietf.org
> Ä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
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb