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

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:rtcweb-bounces@ietf.org] On Behalf Of Justin
> Uberti
> Sent: 08 January 2015 21:06
> To: Benjamin Schwartz
> Cc: Cullen Jennings; rtcweb@ietf.org
> Subject: Re: [rtcweb] Discussion of draft-schwartz-rtcweb-return-04
> 
> 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).
>    ----------------------------------------------------------------
> 
> 
> 
> On Thu, Jan 8, 2015 at 11:34 AM, Benjamin Schwartz <bemasc@webrtc.org>
> wrote:
> 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 <ted.ietf@gmail.com> wrote:
> 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
> 
> _______________________________________________
> 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