Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP?

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

>>     F18     The browser must be able to send streams and
>>             data to a peer in the presence of NATs and
>>             Firewalls that block UDP traffic.

>Yes. Using TURN servers is the way in which it is possible to fulfil this
requirement.

Further in draft-ietf-rtcweb-use-cases-and-requirements-14: 
"the straddling TURN server ... It must be
   possible to configure the browsers used in the enterprise with
   network specific STUN and TURN servers.  This should be possible to
   achieve by auto-configuration methods."
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).

This is a TURN server with one interface on the Enterprise LAN where the
browser 
simple shall place the WebRTC media. (The other interface should be public.)

The way for the browser to autodiscover such network provided (from the
enterprise and ISP) TURN server is being worked in
draft-patil-tram-turn-serv-disc-01.txt.

This resolves any firewall restriction not allowing WebRTC media (by
paralleling the firewall with the TURN server), and also allows the
enterprise or ISP to point out a better path for the WebRTC media (instead
of through the often data crowded firewall default gateway).
(This will also be needed with IPv6.)

/Karl

-----Ursprungligt meddelande-----
Från: rtcweb [mailto:[e-mail]] För Harald Alvestrand
Skickat: den 12 juni 2014 06:17
Till: Makaraju, Maridi Raju (Raju); Sergio Garcia Murillo; Javier Cerviño
Kopia: [e-mail]
Ämne: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to
UDP?

On 06/11/2014 08:38 PM, Makaraju, Maridi Raju (Raju) wrote:
>> The MUST was a consensus call in London. See the minutes for numbers. I
was one of >the ones who were surprised at the strength of the consensus.
> [Raju] I thought one of the implicit (may be explicit in
draft-ietf-rtcweb-use-cases-and-requirements-14) requirement for WebRTC is
"implementations should work right out of the box without extra boxes (e.g.
TURN) in between under UDP restrictive firewalls".
Unfortunately, nobody's found a way to make that true even for all common
NATs/firewalls that want to permit the communication.

TURN servers are the least obnoxious way to make sure apps can work in the
presence of symmetric NATs.
We could wish that this wasn't so, but we could also wish that NATs would go
away and everyone would run IPv6; neither is likely to happen this year.

Of course, in the presence of firewalls where the admin does *not* want to
permit the communication, we neither can nor should make communication work.


> Then I see the following requirement in
draft-ietf-rtcweb-use-cases-and-requirements-14. It did not mention use of
TURN in the text.
>
>     F18     The browser must be able to send streams and
>             data to a peer in the presence of NATs and
>             Firewalls that block UDP traffic.

Yes. Using TURN servers is the way in which it is possible to fulfil this
requirement.

>
> BR
> Raju
>

_______________________________________________
rtcweb mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rtcweb