Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP?
"Karl Stahl" <karl.stahl@intertex.se> Fri, 13 June 2014 12:54 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 B6CA61B2817 for <rtcweb@ietfa.amsl.com>; Fri, 13 Jun 2014 05:54:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.6
X-Spam-Level:
X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_LOW=-0.7] 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 9ucLsfmDReH8 for <rtcweb@ietfa.amsl.com>; Fri, 13 Jun 2014 05:54:52 -0700 (PDT)
Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.161]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D15DF1A04CA for <rtcweb@ietf.org>; Fri, 13 Jun 2014 05:54:50 -0700 (PDT)
Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201406131454452773; Fri, 13 Jun 2014 14:54:45 +0200
From: Karl Stahl <karl.stahl@intertex.se>
To: 'Harald Alvestrand' <harald@alvestrand.no>, "'Pal Martinsen (palmarti)'" <palmarti@cisco.com>
References: <CAOJ7v-2FTAKGd2ZUNt9PZBW9pFu7c9v7Gx8Z8vFOQo4K3dyr5Q@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D35B859@ESESSMB209.ericsson.se> <CALiegfn7WuyA8qbKWGs4JrNutqF9teXiEN8eqd0UJk5vRrX4TQ@mail.gmail.com> <539786C7.8090806@gmail.com> <E1FE4C082A89A246A11D7F32A95A17828E406A88@US70UWXCHMBA02.zam.alcatel-lucent.com> <CAG=SL7mGHuP0KBuvPGQ8bG0+CxHB7WjemCxZ5WxCXB8XgpOhCQ@mail.gmail.com> <E1FE4C082A89A246A11D7F32A95A17828E407D35@US70UWXCHMBA02.zam.alcatel-lucent.com> <53984062.1090202@gmail.com> <E1FE4C082A89A246A11D7F32A95A17828E407F64@US70UWXCHMBA02.zam.alcatel-lucent.com> <53986129.4050209@gmail.com> <E1FE4C082A89A246A11D7F32A95A17828E40858D@US70UWXCHMBA02.zam.alcatel-lucent.com> <53987FC3.7060408@gmail.com> <6025bc75-db01-45d4-ac4a-50a39740f15a@email.android.com> <E1FE4C082A89A246A11D7F32A95A17828E408FC8@US70UWXCHMBA02.zam.alcatel-lucent.com> <539929C1.3070 205@alvestrand.no> <017301cf8624$d4a68060$7df38120$@stahl@intertex.se> <057DC1BB-CEDA-4E28-A9EC-41C3FE5673F3@cisco.com> <5399BFE6.5050 003@alvestrand.no>
In-Reply-To: <5399BFE6.5050003@alvestrand.no>
Date: Fri, 13 Jun 2014 14:54:48 +0200
Message-ID: <00a601cf8706$a89a1ee0$f9ce5ca0$@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: Ac+GTq58opzbmTCNTUCGD1WeAsVMVgAqQ/6Q
Content-Language: sv
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/5JEQdGkpgnXw2WrCn27OYQD0Orc
Cc: 'Javier Cerviño' <jcague@gmail.com>, rtcweb@ietf.org
Subject: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP?
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: Fri, 13 Jun 2014 12:54:54 -0000
Below I am agreeing with Harald that WebRTC browsers need to auto-discover and use network provided TURN servers in favor of application provided TURN servers (that will still remain with its hassles and limitations, for some time of course). --> /Karl -----Ursprungligt meddelande----- Från: Harald Alvestrand [mailto:harald@alvestrand.no] Skickat: den 12 juni 2014 16:58 Till: Pal Martinsen (palmarti); Karl Stahl Kopia: Makaraju, Maridi Raju (Raju); Sergio Garcia Murillo; Javier Cerviño; rtcweb@ietf.org Ämne: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP? On 06/12/2014 01:30 PM, Pal Martinsen (palmarti) wrote: > On 12 Jun 2014, at 11:58, Karl Stahl <karl.stahl@intertex.se> wrote: > >>>> 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.) >> > I have problems understanding how this solves any issues. I doubt many enterprise network managers would install a TURN server in parallel with their FW. Would be fair easier and safer to open up the appropriate ports in the firewall towards the TURN server. They could then allow only UDP to allow for DPI and see that it is actually RTP traffic flowing. That is actually a very convenient way to (logically) install a TURN server in parallel with your firewall. They don't have to be on the same physical segments to be in parallel. The important thing that Cullen (I think it was Cullen) pointed out when we discussed this requirement is that the TURN server is designated by the local network administrator, not by the entity responsible for the Web application that uses WebRTC. [Karl] I fully agree with this - The WebRTC application should be off-loaded of having to provide a TURN-server to allow usage behind (some) NAT/firewalls (and we should not put that burden on the peer either). This is something we do today to get something going (but still don't succeed with the most restrictive firewalls), but hopefully don't have to do in the future on "WebRTC-ready" accesses. Such accesses simply put ICE initiated real-time traffic through the TURN server, while data goes as usual through the default gateway (in a future clever firewall/NAT this can be the same default gateway IP-address). [Karl] Yes, let's hope for network provided turn servers, which could be boxes in parallel with existing firewalls or built into the firewall. (A turn server is much cleaner and better standardized to integrate, than non-working SIP ALGs, where we instead put SBCs in parallel with firewalls just to get SIP voice through (and with quality)). [Karl] Also consider all triple play (surf/telephony/IP-TV) broadband accesses, that have a quality pipe just to cope with voice. A turn server in such CPE will be required to place demanding WebRTC media on the pipe that can handle WebRTCs real-time traffic. Separate pipes are also often deployed e.g. for SIP trunking enterprise voice (PBXs and UC) paralleling the firewall. A local turn server could similarly feed WebRTC media into such pipes, then bypassing the ordinary firewall (that may be too restrictive to allow real-time traffic or just is too data crowded to cope with WebRTC media - NAT/Firewalls are typical congestion points). Harald> Thus, some way for the browser to find this TURN server is needed. [Karl] Auto discovered, network provided (enterprise or ISP) turn servers are being done in draft-patil-tram-turn-serv-disc-01.txt. I favor the anycast method suggested. Will WebRTC browsers implement all auto discovery methods suggested there? [Karl] Network provided turn servers available for the network users, need no authentication - The WebRTC browser can just use them as part of the Internet access (you get an IP address, a default gateway and a turn server address to simply use). Those turn servers are required/can solve both traversal and quality problems of many internet accesses. > > Having a TURN server supporting UDP/TCP/TLS as communication between the client and TURN server would solve almost all connectivity problems. We should, as Harald also pointed out, not try to force us throughout the FW if the admin do not want the traffic to go through. > > .-. > Pål-Erik > > > > > > > > > > >> /Karl >> >> -----Ursprungligt meddelande----- >> Från: rtcweb [mailto:rtcweb-bounces@ietf.org] För Harald Alvestrand >> Skickat: den 12 juni 2014 06:17 >> Till: Makaraju, Maridi Raju (Raju); Sergio Garcia Murillo; Javier >> Cerviño >> Kopia: rtcweb@ietf.org >> Ä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 >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb
- [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE:… Justin Uberti
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Makaraju, Maridi Raju (Raju)
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Christer Holmberg
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Eric Rescorla
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Lorenzo Miniero
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Makaraju, Maridi Raju (Raju)
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Iñaki Baz Castillo
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Christer Holmberg
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Justin Uberti
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Iñaki Baz Castillo
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Eric Rescorla
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Iñaki Baz Castillo
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Eric Rescorla
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Makaraju, Maridi Raju (Raju)
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Justin Uberti
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Suhas Nandakumar
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Christer Holmberg
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Christer Holmberg
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Makaraju, Maridi Raju (Raju)
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Makaraju, Maridi Raju (Raju)
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Iñaki Baz Castillo
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Makaraju, Maridi Raju (Raju)
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Iñaki Baz Castillo
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Makaraju, Maridi Raju (Raju)
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Eric Rescorla
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Christer Holmberg
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Makaraju, Maridi Raju (Raju)
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Christer Holmberg
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Christer Holmberg
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Makaraju, Maridi Raju (Raju)
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Christer Holmberg
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Makaraju, Maridi Raju (Raju)
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Makaraju, Maridi Raju (Raju)
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Harald Alvestrand
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Harald Alvestrand
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Makaraju, Maridi Raju (Raju)
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Enrico Marocco
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Christer Holmberg
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Justin Uberti
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Roman Shpount
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Makaraju, Maridi Raju (Raju)
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Harald Alvestrand
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Makaraju, Maridi Raju (Raju)
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Sergio Garcia Murillo
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Justin Uberti
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Makaraju, Maridi Raju (Raju)
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Christer Holmberg
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Iñaki Baz Castillo
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Christer Holmberg
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Hutton, Andrew
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Harald Alvestrand
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Iñaki Baz Castillo
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Sergio Garcia Murillo
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Makaraju, Maridi Raju (Raju)
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Christer Holmberg
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Makaraju, Maridi Raju (Raju)
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Sergio Garcia Murillo
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Makaraju, Maridi Raju (Raju)
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Sergio Garcia Murillo
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Makaraju, Maridi Raju (Raju)
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Sergio Garcia Murillo
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Harald Alvestrand
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Makaraju, Maridi Raju (Raju)
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Sergio Garcia Murillo
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Harald Alvestrand
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Karl Stahl
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Pal Martinsen (palmarti)
- Re: [rtcweb] Need for TURN, TCP-ICE (was Retry: D… Makaraju, Maridi Raju (Raju)
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Ca By
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Harald Alvestrand
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Iñaki Baz Castillo
- Re: [rtcweb] Need for TURN, TCP-ICE (was Retry: D… Roman Shpount
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Roman Shpount
- Re: [rtcweb] Need for TURN, TCP-ICE (was Retry: D… Makaraju, Maridi Raju (Raju)
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Makaraju, Maridi Raju (Raju)
- Re: [rtcweb] Need for TURN, TCP-ICE (was Retry: D… Roman Shpount
- Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over … Karl Stahl
- Re: [rtcweb] Need for TURN, TCP-ICE (was Retry: D… Karl Stahl
- Re: [rtcweb] Need for TURN, TCP-ICE (was Retry: D… Makaraju, Maridi Raju (Raju)
- Re: [rtcweb] Need for TURN, TCP-ICE (was Retry: D… Justin Uberti
- Re: [rtcweb] Need for TURN, TCP-ICE (was Retry: D… Roman Shpount
- Re: [rtcweb] Need for TURN, TCP-ICE (was Retry: D… Justin Uberti