Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-requirements-12

Magnus Westerlund <> Wed, 15 January 2014 10:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7F0551AE33E for <>; Wed, 15 Jan 2014 02:34:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5sFUkemHUmwJ for <>; Wed, 15 Jan 2014 02:34:44 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 80B5E1AE31B for <>; Wed, 15 Jan 2014 02:34:43 -0800 (PST)
X-AuditID: c1b4fb38-b7f2c8e000006d25-83-52d664375885
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 11.5C.27941.73466D25; Wed, 15 Jan 2014 11:34:31 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id 14.2.347.0; Wed, 15 Jan 2014 11:34:31 +0100
Message-ID: <>
Date: Wed, 15 Jan 2014 11:34:18 +0100
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Parthasarathi R <>, "'Chenxin (Xin)'" <>, "'Hutton, Andrew'" <>, 'Christer Holmberg' <>,
References: <> <00d601cec911$b0fd4b60$12f7e220$> <> <> <> <> <> <> <000d01cecdb2$63c1ef90$2b45ceb0$>
In-Reply-To: <000d01cecdb2$63c1ef90$2b45ceb0$>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFLMWRmVeSWpSXmKPExsUyM+Jvja55yrUgg1crxC22bSi1uHmll9Fi 8qc+Vou1/9rZHVg8Wo68ZfVYsuQnk8eH+V/YPbb3PGYJYInisklJzcksSy3St0vgyti0uJOp 4INIxb4NLewNjFsFuhg5OSQETCROv7nNDGGLSVy4t56ti5GLQ0jgCKPEyd3dzBDOckaJrvt3 2UCqeAW0JTauXABmswioSkyddAPMZhOwkLj5oxHMFhUIlrg17QE7RL2gxMmZT1hABokI3GGU uLrsHRNIQlggTOL2ktUsEBsOsUjcf/+WFSTBCXTTit6TQAkOoJvEJXoag0DCzAJ6ElOutjBC 2PISzVtng50tBHRQQ1MH6wRGwVlI9s1C0jILScsCRuZVjBzFqcVJuelGBpsYgeF7cMtvix2M l//aHGKU5mBREuf9+NY5SEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAMjV07zMl/+yOtH7snu ibq3qyPi+znnwNzgWYd0NxQum/Woyo/l6b3qd/H2Vgpa7w6zxwpX9H+suD9h9lsWG++Lq53Y g9we+x2awfJQ6t60TI/dXA7y1xa/sTe4f/Hf3ZTngnfe/jt/YeN312c6sx+Wck6ffKPzzGqd Lt8zzLc+d0b6XPyz5pWEphJLcUaioRZzUXEiANRUCHAtAgAA
Subject: Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-requirements-12
X-Mailman-Version: 2.1.15
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: Wed, 15 Jan 2014 10:34:45 -0000

Hi Partha,

I see this as an outstanding question on the use-cases document and I
want to resolve it prior to the publication request.

I want to check my understanding of the points you bring up. See below.

On 2013-10-20 18:35, Parthasarathi R wrote:
> Hi Xin & all,
> Apart from modified F29 by Xin, the following requirement has to be
> discussed:
> 1)      New requirement for blocking incoming TCP connection:
> a.        The browser must be able to send streams and data to a peer in
> the presence of NATs and FWs that block UDP traffic and incoming TCP
> connection

So the point of this requirement would be to differentiate to the other
existing requirements that a NAT/FW combination may provide no UDP and
no support for incoming TCP. Thus, if one goes into solution space, you
need a proxy/relay solution where a peer can establish a point of
presence outside of the NAT/FW which is reachable over non-UDP, thus
assuming TCP as only alternative.

>From my perspective the combination of F2 and F29 implicitly demands the
support of a relay solution, and that it is unnecessary to add an
explicit requirement. This as the failure rate for incoming TCP
connections through any NAT is high irrespective of explicit blocking of
incoming TCP or not.

> 2)      New requirement to cover both browsers are behind the firewall
> a.         The browser must be able to send streams and data to a peer
> in the presence of NATs and FWs that block UDP traffic and incoming TCP
> connection  in both browser side as well as in the peer side (TURN only
> works)

I think this is unclear, as there are two aspects of this. The peers are
either behind different FW or the same FW/NAT. If it is the second, I
think this will simply work the same way two client on an non firewalled
network would work. At least ICE will find it. If it is the first, I
think that is implicitly included in F2.

Thus I question if there any utility in adding anything about this in
the use-case document.

WG, please contribute your views on this and if we need to make any
changes to the document in regards to this proposal.


Magnus Westerlund

Services, Media and Network features, Ericsson Research EAB/TXM
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: