Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
"Hutton, Andrew" <andrew.hutton@siemens-enterprise.com> Sat, 21 September 2013 23:40 UTC
Return-Path: <andrew.hutton@siemens-enterprise.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1C3B11E81D5 for <rtcweb@ietfa.amsl.com>; Sat, 21 Sep 2013 16:40:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.569
X-Spam-Level:
X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHJAFboAbmGI for <rtcweb@ietfa.amsl.com>; Sat, 21 Sep 2013 16:40:54 -0700 (PDT)
Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 21AB311E81D7 for <rtcweb@ietf.org>; Sat, 21 Sep 2013 16:40:54 -0700 (PDT)
Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 7DB471EB855A; Sun, 22 Sep 2013 01:40:53 +0200 (CEST)
Received: from MCHP04MSX.global-ad.net ([169.254.1.31]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003; Sun, 22 Sep 2013 01:40:38 +0200
From: "Hutton, Andrew" <andrew.hutton@siemens-enterprise.com>
To: Karl Stahl <karl.stahl@intertex.se>, 'Magnus Westerlund' <magnus.westerlund@ericsson.com>, "'Cullen Jennings (fluffy)'" <fluffy@cisco.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>, "draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org" <draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org>
Thread-Topic: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
Thread-Index: AQHOs51tjte/V8mikk+NN5idi26Ro5nO5Y8ggABAlmCAAbVQhg==
Date: Sat, 21 Sep 2013 23:40:37 +0000
Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17BD02D4@MCHP04MSX.global-ad.net>
References: <C5E08FE080ACFD4DAE31E4BDBF944EB11667BBA0@xmb-aln-x02.cisco.com> <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net>, <07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se>
In-Reply-To: <07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.29.42.196]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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: Sat, 21 Sep 2013 23:40:58 -0000
See below. ________________________________________ From: Karl Stahl [karl.stahl@intertex.se] Sent: Friday, September 20, 2013 11:11 PM To: Hutton, Andrew; 'Magnus Westerlund'; 'Cullen Jennings (fluffy)'; rtcweb@ietf.org; draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org Subject: SV: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 I want to point out that all methods suggested for RTP media through firewalls that do not allow UDP traffic, by using "always open" https port 443 (or http port 80) result in tunneling RTP media over TCP. That gives with severe quality problems from TCP retransmissions of dropped media packet packets. Do we really want that for WebRTC? A quality wise better solution is already pointed out in use case 3.2.5.1 mentioned below: "An enterprise that uses a RTCWEB based web application for communication desires to audit all RTCWEB based application session used from inside the company towards any external peer. To be able to do this they deploy a TURN server that straddle the boundary between the internal network and the external" [AndyH] This is not about which is the better solution it is simply describing use cases. One in which the network administrator is aware of WebRTC and deploys mechanisms to deal with it and one in which there is no administrator or network specific mechanism for handling WebRTC media. I think the use case in which there is no network specific TURN server will be at least in the near term by far the most common use case and therefore we need mechanisms to deal with it and it is a valid use case. I suggest the following is added to that use case: "Such TURN server allows a media path, separated from the usually data crowded enterprise Internet access, offering superior quality. This is a better way to enable WebRTC on a network behind a restrictive firewall not allowing UDP traffic, instead of tunneling RTP through always open http or https ports resulting in RTP media over TCP – with severe quality problems from TCP retransmissions of dropped packets. [AndyH] This does not sound like use case text to me it is comparing solutions to different use cases. Such network administrator provided auditing TURN server would also put the right party in control – The network administrator decides what is allowed on his network." Why should a network administrator that wants to block webrtc media, have to do more than just closing his firewall for UDP, like below suggested "configuring the browser not to do webrtc, normal HTTP black/white lists, and solutions based on putting something in the HTTP Connect sent to the proxy so the proxy can block it"? [AndyH] The use case of most concern is the one where there is no network administrator and we need WebRTC to work in those environments by default if that means an administrator who is WebRTC aware has to go to a little effort to block it then I think that is ok. Another thing in the second half of the same use case 3.2.5.1: Are NAT/firewalls inside the enterprise network assumed? If not, I think the second half can be deleted. " In cases where employees are using RTCWEB applications provided by an external service provider they still want to have the traffic to stay inside their internal network and in addition not load the straddling TURN server, " ICE establishes a direct connection in this case, not using any TURN server at all, doesn’t it? This is then not a problem. /Karl -----Ursprungligt meddelande----- Från: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] För Hutton, Andrew Skickat: den 20 september 2013 19:58 Till: Magnus Westerlund; Cullen Jennings (fluffy); rtcweb@ietf.org; draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org Ämne: Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 On: 17 September 2013 13:01 Magnus Westerlund Wrote: > 3.2.3.1. Description > > This use-case is almost identical to the Simple Video Communication > Service use-case (Section 3.2.1). The difference is that one of the > users is behind a FW that only allows http traffic. > > If a firewall only allows HTTP traffic, then can we really assume that > the firewall administrator per default will accept WebRTC Media and > Data traffic? > > I am far from certain of this, and think on a requirement level needs > to express a situation where the firewall administrator allows WebRTC > across its FW, or at least can easily configure a rule to block it. > Thus > resulting in that any solution for this needs to be easily > identifiable and possible to block. > Stefan already stated that this use case will be changed to take account of my comments in http://www.ietf.org/mail-archive/web/rtcweb/current/msg08264.html. So the "only allows HTTP traffic" is going to be removed and changed to describe the use case when the firewall requires traffic to flow via a HTTP Proxy. We also have a use case when a network specific TURN server is deployed (3.2.5.1). In both cases I agree that a network administrator must have a way to block webrtc but there are various ways of achieving this including just configuring the browser not to do webrtc, normal HTTP black/white lists, and also I can imagine solutions based on putting something in the HTTP Connect sent to the proxy so the proxy can block it. So I agree that it must be possible to block webrtc traffic but we need to careful not to specify the solution in the use case. Andy _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
- [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-… Cullen Jennings (fluffy)
- Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-… Stefan Håkansson LK
- Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-… Magnus Westerlund
- Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-… Bernard Aboba
- [rtcweb] TURN server address via DHCP, WGLC of dr… Karl Stahl
- Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-… Hutton, Andrew
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Harald Alvestrand
- Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-… Karl Stahl
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Bernard Aboba
- [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-… Karl Stahl
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Marc Abrams
- [rtcweb] [mmusic] WGLC of draft-ietf-rtcweb-use-c… Karl Stahl
- [rtcweb] [mmusic] TURN server address via DHCP, W… Karl Stahl
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Hutton, Andrew
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Marc Abrams
- Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-… Hutton, Andrew
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Hutton, Andrew
- Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-… Sergio Garcia Murillo
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Tirumaleswar Reddy (tireddy)
- Re: [rtcweb] TURN server address via DHCP, WGLC o… cb.list6
- Re: [rtcweb] [mmusic] WGLC of draft-ietf-rtcweb-u… Dan Wing
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Karl Stahl
- Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-… Chenxin (Xin)
- Re: [rtcweb] additional ICE info Bernard Aboba
- Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-… Karl Stahl
- Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-… Chenxin (Xin)
- Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-… Karl Stahl
- Re: [rtcweb] additional ICE info Dan Wing
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Cullen Jennings (fluffy)
- Re: [rtcweb] additional ICE info Harald Alvestrand
- Re: [rtcweb] additional ICE info Dan Wing
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Karl Stahl
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Harald Alvestrand
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Markus.Isomaki
- Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-… Chenxin (Xin)
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Karl Stahl
- Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-… Karl Stahl
- Re: [rtcweb] TURN server address via DHCP, WGLC o… cb.list6
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Cullen Jennings (fluffy)
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Justin Uberti
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Karl Stahl
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Jeremy Laurenson (jlaurens)
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Justin Uberti
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Martin Thomson
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Bernard Aboba
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Jeremy Laurenson (jlaurens)
- [rtcweb] [mmusic] TURN server address via DHCP, W… Karl Stahl
- Re: [rtcweb] [mmusic] WGLC of draft-ietf-rtcweb-u… Magnus Westerlund
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Saverio Vardaro
- Re: [rtcweb] additional ICE info Martin Thomson
- Re: [rtcweb] [mmusic] WGLC of draft-ietf-rtcweb-u… Karl Stahl
- Re: [rtcweb] [mmusic] TURN server address via DHC… Cullen Jennings (fluffy)
- Re: [rtcweb] [mmusic] TURN server address via DHC… Karl Stahl
- Re: [rtcweb] [mmusic] WGLC of draft-ietf-rtcweb-u… Christer Holmberg
- Re: [rtcweb] [mmusic] TURN server address via DHC… Justin Uberti
- Re: [rtcweb] [mmusic] TURN server address via DHC… cb.list6
- [rtcweb] Payload Types assignments was Re: SV: [m… Magnus Westerlund
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Karl Stahl
- Re: [rtcweb] [mmusic] TURN server address via DHC… Karl Stahl
- Re: [rtcweb] [mmusic] WGLC of draft-ietf-rtcweb-u… Karl Stahl
- Re: [rtcweb] [mmusic] TURN server address via DHC… Justin Uberti
- Re: [rtcweb] Payload Types assignments was Re: SV… Karl Stahl
- Re: [rtcweb] Payload Types assignments was Re: SV… Harald Alvestrand
- Re: [rtcweb] Payload Types assignments was Re: SV… BeckW
- Re: [rtcweb] Payload Types assignments was Re: SV… Ted Hardie
- Re: [rtcweb] Payload Types assignments was Re: SV… BeckW
- Re: [rtcweb] Payload Types assignments was Re: SV… Harald Alvestrand
- Re: [rtcweb] Payload Types assignments was Re: SV… Martin Thomson
- Re: [rtcweb] Payload Types assignments was Re: SV… Harald Alvestrand
- Re: [rtcweb] Payload Types assignments was Re: SV… BeckW
- Re: [rtcweb] Payload Types assignments was Re: SV… Martin Thomson
- Re: [rtcweb] Payload Types assignments was Re: SV… Ted Hardie
- Re: [rtcweb] Payload Types assignments was Re: SV… Lee, Richard FTC
- Re: [rtcweb] Payload Types assignments was Re: SV… Dan Wing
- Re: [rtcweb] Payload Types assignments was Re: SV… BeckW
- Re: [rtcweb] Payload Types assignments was Re: SV… Karl Stahl
- [rtcweb] [mmusic] Anycast discovery, Was TURN ser… Karl Stahl
- [rtcweb] [avtext] Payload Types assignments was R… Karl Stahl
- [rtcweb] [tram] Payload Types assignments Karl Stahl
- Re: [rtcweb] [tram] Payload Types assignments Colin Perkins
- Re: [rtcweb] [tram] Payload Types assignments Karl Stahl
- Re: [rtcweb] [tram] Payload Types assignments Magnus Westerlund
- Re: [rtcweb] [tram] Payload Types assignments Charles Eckel (eckelcu)
- Re: [rtcweb] [tram] Payload Types assignments Colin Perkins
- Re: [rtcweb] [tram] Payload Types assignments Harald Alvestrand
- Re: [rtcweb] [tram] Payload Types assignments Karl Stahl
- Re: [rtcweb] [tram] Payload Types assignments Karl Stahl
- Re: [rtcweb] [tram] Payload Types assignments Karl Stahl
- Re: [rtcweb] [tram] Payload Types assignments Harald Alvestrand
- Re: [rtcweb] [tram] Payload Types assignments Karl Stahl