Re: [pntaw] Real-time media over TCP

Harald Alvestrand <> Tue, 03 September 2013 18:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B2EB021F9CA1 for <>; Tue, 3 Sep 2013 11:11:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.536
X-Spam-Status: No, score=-110.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Q3xLGw17SlQJ for <>; Tue, 3 Sep 2013 11:11:40 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CE29421F9BB4 for <>; Tue, 3 Sep 2013 11:11:39 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4F85F39E469; Tue, 3 Sep 2013 20:11:37 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mz06qKfitSYG; Tue, 3 Sep 2013 20:11:36 +0200 (CEST)
Received: from (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by (Postfix) with ESMTPSA id 60ADA39E03B; Tue, 3 Sep 2013 20:11:36 +0200 (CEST)
Message-ID: <>
Date: Tue, 03 Sep 2013 20:11:35 +0200
From: Harald Alvestrand <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8
MIME-Version: 1.0
To: Dan Wing <>
References: <> <> <BLU405-EAS183E36A927CA42270B6936D93300@phx.gbl> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Bernard Aboba <>, "" <>
Subject: Re: [pntaw] Real-time media over TCP
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion list for practices related to proxies, NATs, TURN, and WebRTC" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 03 Sep 2013 18:11:44 -0000

On 09/03/2013 07:25 PM, Dan Wing wrote:
>> Multiple TCP connections seems like a suboptimal design, given the existence of other solutions like Minion or SCTP.
> Sure.  But those technologies weren't on the table when Victor did interactive audio/video over TCP, I'm sure.  Much like they weren't on the table when HTTP started doing multiple TCP connections back in the early days of Netscape.

Victor didn't provide a date, so I was thinking "recently" - SCTP is 10 
years old at this point.
Minion is newer than that, of course.
>> If both sides have TURN over TCP (or TURN over HTTP) enabled, and their respective TURN servers can talk UDP to each other, communication will occur, I think. I don't think we need to add TCP candidates for the TURN case in order to bypass firewalls.
>> We might want to do so for the benefit of the pure peer-to-peer case, but I'm not sure it's a case that's important enough to make 6062 (TURN TCP allocations) or 6544 (ICE TCP allocations, no TURN server) into MUSTs for RTCWEB.
> I agree.  Additionally, before anyone ventures too far down that path it would be useful to understand how well the expected RTCWeb endpoints could do peer-to-peer TCP connections.  Reliable peer-to-peer TCP needs TCP simultaneous open needs to work well on both hosts, per the research by Saikat Guha and Paul Francis  In that research, they found Windows XP SP1 doesn't do simultaneous open well, but Windows XP with SP2 and SP3 and Linux worked okay.  I have not seen similar research for Android, OS X, or Windows 7 or Windows 8.
Indeed; that article seemed to indicate that the brand of NAT you bought 
was a decisive factor - it would be interesting to see if the state of 
the art has become more or less symmetric-TCP hostile in the intervening 
8 years.