Re: [rtcweb] RETURN-05

"Karl Stahl" <karl.stahl@intertex.se> Wed, 11 March 2015 00:31 UTC

Return-Path: <karl.stahl@intertex.se>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9DE11A8AC2 for <rtcweb@ietfa.amsl.com>; Tue, 10 Mar 2015 17:31:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.9
X-Spam-Level:
X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ey8GrIQ4rCbC for <rtcweb@ietfa.amsl.com>; Tue, 10 Mar 2015 17:31:11 -0700 (PDT)
Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.162]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FAC51A884C for <rtcweb@ietf.org>; Tue, 10 Mar 2015 17:31:10 -0700 (PDT)
Received: from ([90.227.80.227]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201503110131076177; Wed, 11 Mar 2015 01:31:07 +0100
From: Karl Stahl <karl.stahl@intertex.se>
To: 'Randell Jesup' <randell-ietf@jesup.org>, rtcweb@ietf.org, 'Alan Johnston' <alan.b.johnston@gmail.com>, "'Hutton, Andrew'" <andrew.hutton@unify.com>, 'Simon Perreault' <sperreault@jive.com>
References: <CAHbrMsA2TdSAL0KefqctG7UG549UG2V9XxFYX6_RbkuGmMSmqw@mail.gmail.com> <CAKhHsXGcnyW05HDNqccM+-fCO9aJFLgNSbG=NKUe78y-QK8FVA@mail.gmail.com> <54FEF599.5030002@jesup.org>
In-Reply-To: <54FEF599.5030002@jesup.org>
Date: Wed, 11 Mar 2015 01:30:58 +0100
Message-ID: <1f1e01d05b92$a4f90380$eeeb0a80$@stahl>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AdBbOJYzY16R6GTqSBuCNfbenqcL/AAV74+g
Content-Language: sv
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/2o44tpIEMpJC4eM8QTvT1GNk8-U>
Subject: Re: [rtcweb] RETURN-05
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Mar 2015 00:31:13 -0000

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


-----Ursprungligt meddelande-----
Från: rtcweb [mailto:rtcweb-bounces@ietf.org] För Randell Jesup
Skickat: den 10 mars 2015 14:46
Till: rtcweb@ietf.org
Ämne: Re: [rtcweb] RETURN-05

On 3/9/2015 1:39 PM, Alan Johnston wrote:
> 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.

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

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb