Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11

"Hutton, Andrew" <> Fri, 20 September 2013 17:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 56E5D21F9CED for <>; Fri, 20 Sep 2013 10:58:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.577
X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YfIQhTiS-v6i for <>; Fri, 20 Sep 2013 10:57:57 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AAAFD21F9CE9 for <>; Fri, 20 Sep 2013 10:57:56 -0700 (PDT)
Received: from (unknown []) by (Server) with ESMTP id C67DF23F0542; Fri, 20 Sep 2013 19:57:53 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Fri, 20 Sep 2013 19:57:39 +0200
From: "Hutton, Andrew" <>
To: Magnus Westerlund <>, "Cullen Jennings (fluffy)" <>, "" <>, "" <>
Thread-Topic: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
Thread-Index: AQHOs51tjte/V8mikk+NN5idi26Ro5nO5Y8g
Date: Fri, 20 Sep 2013 17:57:38 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 20 Sep 2013 17:58:07 -0000

On: 17 September 2013 13:01 Magnus Westerlund Wrote:
>  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 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 (

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.