Re: [rtcweb] Comments on draft-ietf-rtcweb-transports-01

Simon Perreault <> Wed, 13 November 2013 18:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0F56C11E8126 for <>; Wed, 13 Nov 2013 10:57:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jpwt9zVjOhvP for <>; Wed, 13 Nov 2013 10:57:39 -0800 (PST)
Received: from ( [IPv6:2620:0:230:8000::2]) by (Postfix) with ESMTP id 2530611E8107 for <>; Wed, 13 Nov 2013 10:57:39 -0800 (PST)
Received: from (unknown [IPv6:2620:0:230:c000:d5d4:b853:2212:f683]) by (Postfix) with ESMTPSA id 7DABB403CF; Wed, 13 Nov 2013 13:57:38 -0500 (EST)
Message-ID: <>
Date: Wed, 13 Nov 2013 13:57:38 -0500
From: Simon Perreault <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Harald Alvestrand <>, "Ravindran, Parthasarathi (NSN - IN/Bangalore)" <>, ext Magnus Westerlund <>, "" <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-transports-01
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: Wed, 13 Nov 2013 18:57:40 -0000

Le 2013-11-13 13:44, Harald Alvestrand a écrit :
>> All this relies on the possibility that a TCP peer-to-peer connection
>> could be successfully established where a UDP one couldn't. IMHO this
>> is very unlikely to happen in practice. So unlikely in fact that any
>> possible gain over just falling back on a TURN relay wouldn't be worth
>> the additional implementation cost.
> Simon, do you have any numbers on that - how many calls will be going to
> servers on the Internet versus how many calls will be going peer-to-peer?

Not sure what you mean.

> The argument being given only applies to the client-to-gateway usecase

My point only applied to peer-to-peer connections, not peer-to-server. 
If we're discussing peer-to-server, then I wonder why we're discussing 
that at all.

> (or to naked destination clients that are not behind a NAT, which
> hopefully will become common once IPv6 gets deployed, but aren't common
> now).

If we eliminate NAT, then we're left with firewalls. To benefit from 
ICE-TCP (i.e. ICE-TCP successfully establishing a peer-to-peer TCP 
connection instead of ICE-UDP falling back on TURN-over-TCP), you would 
need both peers to be behind firewalls that block inbound UDP (through 
hole punching or otherwise) but allow inbound TCP (through simultaneous 
open or otherwise). My personal experience is that this kind of firewall 
configuration would be very rare. Now, take that probability and square 
it since it needs to apply to both peers. You get something very very rare.

DTN made easy, lean, and smart -->
NAT64/DNS64 open-source        -->
STUN/TURN server               -->