Subject: [rtcweb] RETURN-05

From: Benjamin Schwartz <[email-masked]>
Date: Fri, 6 Mar 2015 10:19:53 -0500

New draft of RETURN is up:
http://tools.ietf.org/html/draft-schwartz-rtcweb-return-05

This draft contains a variety of clarifications and changes of emphasis,
and should hopefully now be easier to read and understand.

Thanks to Alan Johnston and John Yoakum for contributing new figures and
detailed text review for this revision.

--Ben

---

From: Alan Johnston <[email-masked]>
Date: Mon, 9 Mar 2015 12:39:09 -0500

I think RETURN is essential for WebRTC to work well across enterprise
borders.  We will increasingly see border TURN servers used by enterprises
to manage and control WebRTC usage, most likely as additions to existing
firewalls and SBCs.  Without RETURN, the usage of border TURN servers will
result in loss of functionality in WebRTC applications that use a TURN
server to provide features in addition to simple NAT traversal.  RETURN
should work perfectly to allow both TURN servers to work, while still
allowing end-to-end encrypted and authenticated media flows.

I’m not aware of any other solutions to the enterprise requirements
identified in Section 3.3.5 of
draft-ietf-rtcweb-use-cases-and-requirements.  I think we need to move
forward with this draft in RTCWEB.

- Alan -

On Fri, Mar 6, 2015 at 9:19 AM, Benjamin Schwartz <[email-masked]> wrote:

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

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 10 Mar 2015 13:39:26 +0000

I agree with Alan’s assessment and also believe that we should move forward with this draft.

Regards
Andy

From: rtcweb [mailto:[email-masked]] On Behalf Of Alan Johnston
Sent: 09 March 2015 17:39
To: Benjamin Schwartz
Cc: [email-masked]
Subject: Re: [rtcweb] RETURN-05

I think RETURN is essential for WebRTC to work well across enterprise borders.  We will increasingly see border TURN servers used by enterprises to manage and control WebRTC usage, most likely as additions to existing firewalls and SBCs.  Without RETURN, the usage of border TURN servers will result in loss of functionality in WebRTC applications that use a TURN server to provide features in addition to simple NAT traversal.  RETURN should work perfectly to allow both TURN servers to work, while still allowing end-to-end encrypted and authenticated media flows.

I’m not aware of any other solutions to the enterprise requirements identified in Section 3.3.5 of draft-ietf-rtcweb-use-cases-and-requirements.  I think we need to move forward with this draft in RTCWEB.

- Alan -

On Fri, Mar 6, 2015 at 9:19 AM, Benjamin Schwartz <[email-masked]<mailto:[email-masked]>> wrote:
New draft of RETURN is up:
http://tools.ietf.org/html/draft-schwartz-rtcweb-return-05

This draft contains a variety of clarifications and changes of emphasis, and should hopefully now be easier to read and understand.

Thanks to Alan Johnston and John Yoakum for contributing new figures and detailed text review for this revision.

--Ben

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

---

From: Simon Perreault <[email-masked]>
Date: Tue, 10 Mar 2015 09:40:11 -0400

> I agree with Alan’s assessment and also believe that we should move

+1

Simon

---

From: Randell Jesup <[email-masked]>
Date: Tue, 10 Mar 2015 09:46:01 -0400

On 3/9/2015 1:39 PM, Alan Johnston wrote:
> borders.  We will increasingly see border TURN servers used by 
> enterprises to manage and control WebRTC usage, most likely as 
> additions to existing firewalls and SBCs.  Without RETURN, the usage 
> of border TURN servers will result in loss of functionality in WebRTC 
> applications that use a TURN server to provide features in addition to 
> simple NAT traversal.  RETURN should work perfectly to allow both TURN 
> servers to work, while still allowing end-to-end encrypted and 
> authenticated media flows.
>

I agree.  I'll note that RETURN covers the auto-configuration portion of 
3.3.5, but browsers (and other WebRTC-compatible devices by implication) 
should handle manual configurations as well.  (Just a note, it doesn't 
affect the spec or RETURN I believe.)

    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.

-- 
Randell Jesup -- rjesup a t mozilla d o t com

---

From: "Karl Stahl" <[email-masked]>
Date: Wed, 11 Mar 2015 01:30:58 +0100

I agree with all of you that this draft is very important to move forward
with.

As stated under Figure 2 in the draft:
   ...This TURN server might be used by an enterprise, ISP,
   or home network to enable WebRTC media flows that would otherwise be
   blocked by the firewall, or to improve quality of service on flows
   that pass through this TURN server.  

I see this (in combination with auto discovery of the "Border TURN server")
as necessary
to finally get a proper solution to the NAT/firewall traversal problem that
has plagued 
real-time communication since its occurrence in the IP world.

I hope for quick test implementations in the WebRTC browsers. 

/Karl