Re: [pntaw] Real-time media over TCP

Harald Alvestrand <> Tue, 03 September 2013 07:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2FE1D11E81A1 for <>; Tue, 3 Sep 2013 00:34:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.526
X-Spam-Status: No, score=-110.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id t79Zm9koGCnb for <>; Tue, 3 Sep 2013 00:34:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E5BD511E81A0 for <>; Tue, 3 Sep 2013 00:34:12 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id E10FE39E303; Tue, 3 Sep 2013 09:34:09 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5ORTVkLaWuqM; Tue, 3 Sep 2013 09:34:07 +0200 (CEST)
Received: from (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by (Postfix) with ESMTPSA id 7DB0239E078; Tue, 3 Sep 2013 09:34:07 +0200 (CEST)
Message-ID: <>
Date: Tue, 03 Sep 2013 09:34:06 +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: Bernard Aboba <>
References: <> <> <BLU405-EAS183E36A927CA42270B6936D93300@phx.gbl>
In-Reply-To: <BLU405-EAS183E36A927CA42270B6936D93300@phx.gbl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "" <>
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 07:34:17 -0000

On 09/02/2013 08:17 PM, Bernard Aboba wrote:
> If the issue is firewall restrictions on UDP, then the data channel is not likely to be a workable option. The question for me is how far we need to go to solve this (e.g. RFC 6062? 6544?). The scenario where both sides are behind UDP blocking firewalls is not common, but it does occur.

I was thinking more about "what can you do to avoid TCP's bad behaviour 
for real-time traffic, and still be in a connection-oriented, 
congestion-controlled environment". Multiple TCP connections seems like 
a suboptimal design, given the existence of other solutions like Minion 
or SCTP.

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 

> On Sep 2, 2013, at 1:37 AM, "Harald Alvestrand" <> wrote:
>> On 08/30/2013 12:12 PM, Victor Pascual Avila wrote:
>>> Hi,
>>> Real-time media over TCP has some inherent challenges -- is this
>>> something we're planning to discuss here? We did RTP over TCP (+ HTTP
>>> CONNECT) in the past and ended up using multiple connections along
>>> with application-layer redundancy. I'm wondering whether we'll be able
>>> to do the same when moving to WebRTC
>> If you really want to go there, I suggest you take a good hard look at either SCTP or TCP Minion (draft-iyengar-minion-concept-01.txt).
>> The RTCWeb stack already uses SCTP over DTLS over UDP.
>> In either case, I don't think performance of RTP over reliable transport is a firewall-related issue.
>> _______________________________________________
>> pntaw mailing list