Subject: [rtcweb] Discussion of draft-schwartz-rtcweb-return-04

From: Ted Hardie <[email-masked]>
Date: Thu, 8 Jan 2015 10:54:11 -0800

Howdy,

During the Honolulu meeting, the chairs agreed to ask for some on-list
discussion of this draft prior to discussing adoption.  During the holidays
we dropped the ball on that, for which our apologies.   At this point,
though, we'd like to see some discussion of the draft--in particular on its
scope and how it fits into the landscape of work we need to complete
thanks,

Ted, Cullen, Sean

---

From: Benjamin Schwartz <[email-masked]>
Date: Thu, 8 Jan 2015 14:34:44 -0500

For what it's worth, regarding scope, my perspective is that the document
does not create any new protocol extensions or API points.  Its only
purpose is to lay out in detail the expected interaction between
externally-provided TURN servers (like those found by TRAM autodiscovery)
and WebRTC, which is currently extremely under-specified.  Specifically, it
explains that externally-provided TURN servers are _proxies_, not just
additional TURN servers like those listed in the RTCPeerConnection
constructor arguments.  Treating these servers as proxies (in the
particular manner specified) allows us to preserve (and enhance) some
important performance, connectivity, and privacy properties of WebRTC.

This document only imposes requirements (of any strength) on WebRTC
implementations that intend to implement a mechanism for using TURN servers
that were not indicated by the application.  It does not demand that all
browsers add support for such a mechanism, and it does not specify a
preference for any particular TURN configuration mechanism.

On Thu, Jan 8, 2015 at 1:54 PM, Ted Hardie <[email-masked]> wrote:

> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: Justin Uberti <[email-masked]>
Date: Thu, 8 Jan 2015 13:06:17 -0800

Right. To be absolutely clear, this draft explains how RTCWEB
implementations can satisfy the requirement F20 from Section 3.3.5 of
https://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-15#section-3.3.5.1.
We've discussed the need for this for some time, but the RETURN draft is
the first proposal for how to actually address it.

   ----------------------------------------------------------------
   REQ-ID      DESCRIPTION
   ----------------------------------------------------------------
   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).
   ----------------------------------------------------------------

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 19 Jan 2015 17:27:12 +0000

I think we should do this it is needed and as Justin said it satisfies a requirement (F20) we gave ourselves from the beginning.

I don't see it as something that is mandatory to implement but more of an optimization that is needed to work well in some environments so I would not considered this to be on the critical path but unless somebody proposes an alternative solution to requirement F20 then this should be adopted and done as soon as possible.

Regards
Andy

> -----Original Message-----
> From: rtcweb [mailto:[email-masked]] On Behalf Of Justin
> Uberti
> Sent: 08 January 2015 21:06
> To: Benjamin Schwartz
> Cc: Cullen Jennings; [email-masked]
> Subject: Re: [rtcweb] Discussion of draft-schwartz-rtcweb-return-04
> 
> https://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-
> requirements-15#section-3.3.5.1. We've discussed the need for this for
> some time, but the RETURN draft is the first proposal for how to
> actually address it.
> For what it's worth, regarding scope, my perspective is that the
> document does not create any new protocol extensions or API points.
> Its only purpose is to lay out in detail the expected interaction
> between externally-provided TURN servers (like those found by TRAM
> autodiscovery) and WebRTC, which is currently extremely under-
> specified.  Specifically, it explains that externally-provided TURN
> servers are _proxies_, not just additional TURN servers like those
> listed in the RTCPeerConnection constructor arguments.  Treating these
> servers as proxies (in the particular manner specified) allows us to
> preserve (and enhance) some important performance, connectivity, and
> privacy properties of WebRTC.
> 
> implementations that intend to implement a mechanism for using TURN
> servers that were not indicated by the application.  It does not demand
> that all browsers add support for such a mechanism, and it does not
> specify a preference for any particular TURN configuration mechanism.
> 
> discussion of this draft prior to discussing adoption.  During the
> holidays we dropped the ball on that, for which our apologies.   At
> this point, though, we'd like to see some discussion of the draft--in
> particular on its scope and how it fits into the landscape of work we
> need to complete
> thanks,
> 
> Ted, Cullen, Sean
>