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

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

This is an ICE network infrastructure request (rather than WebRTC specific)
so I am copying MMUSIC.

Harald Alvestrand said: 
> I'm very hesitant to add more requirements that translate to "new protocol
needs to be developed, implemented and deployed across the network before
the requirement is useful".
--- Who isn't? Still the need is there, especially for network providers to
offer TURN servers with their accesses (see below). And worse, it is not 
> "only" a DHCP option
--- it is: "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)"
--- But for the browser it is a trivial thing to implement - Just use the
DHCP provided TURN server address suggested. 

The burden to get the standards done fall on others...

There were some comments seeing the need for local TURN-servers (where there
are other possibilities than the "automatic DHCP", see below), but I want to
stress the importance of allowing network providers to offer TURN servers
with their accesses. That is why I call it a "WebRTC-ready" broadband
access. 

I've heard several carries expressing that they want to provide their own
TURN servers with their accesses. The reason has both been to avoid that
media unnecessarily is sent outside their own network to some remote TURN
server and for quality reasons. The quality reason is especially important
e.g. in cable operator networks, using bandwidth reservation (RSVP) type of
QoS. They need to get hold of the RTP media streams and reserve bandwidth
for them and can do that by enforcing a TURN server at the access to be
used, and that TURN server can classify and reserve the bandwidth. (They do
these things for POTS 3.5kHz voice - They certainly need it for telepresence
capable WebRTC.) 

I think we should be happy and encourage carrier's interest to supply a high
quality path for RTC traffic, here WebRTC. (That is a different attitude
than e.g. trying to block Skype.)

/Karl


-----Ursprungligt meddelande-----
Från: [e-mail] [mailto:[e-mail]] För Karl
Stahl
Skickat: den 20 september 2013 17:44
Till: 'Cullen Jennings (fluffy)'; [e-mail]
Ämne: [rtcweb] TURN server address via DHCP, WGLC of
draft-ietf-rtcweb-use-cases-and-requirements-11

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