Re: [pntaw] Real-time media over TCP

Bernard Aboba <> Mon, 07 October 2013 18:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6A04521E81BD for <>; Mon, 7 Oct 2013 11:32:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.203
X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pdNc-513dt7v for <>; Mon, 7 Oct 2013 11:32:49 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0B70E21E81A1 for <>; Mon, 7 Oct 2013 11:32:48 -0700 (PDT)
Received: from BLU406-EAS274 ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Oct 2013 11:32:48 -0700
X-TMN: [zvfMKlSQ4hBBkftQ+wc2+N2MmmZjwMYo]
X-Originating-Email: []
Message-ID: <BLU406-EAS274696C3D9DFE505F96B8E393130@phx.gbl>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
References: <> <> <BLU405-EAS183E36A927CA42270B6936D93300@phx.gbl> <> <> <> <> <00ca01cec387$f881cae0$e98560a0$>
From: Bernard Aboba <>
MIME-Version: 1.0 (1.0)
In-Reply-To: <00ca01cec387$f881cae0$e98560a0$>
Date: Mon, 7 Oct 2013 11:32:44 -0700
To: Parthasarathi R <>
X-OriginalArrivalTime: 07 Oct 2013 18:32:48.0314 (UTC) FILETIME=[9F7071A0:01CEC38B]
Cc: Harald Alvestrand <>, "" <>, Dan Wing <>
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: Mon, 07 Oct 2013 18:32:53 -0000

As you point out, in most cases ICE-TCP will not avoid use of TURN, so we are only talking about a modest efficiency gain for ICE-TCP and RTP over TCP, but a substantial increase in complexity. 

Running SCTP over TCP is undesirable because the congestion control in SCTP and TCP will interact poorly with each other.  

> On Oct 7, 2013, at 11:07 AM, "Parthasarathi R" <> wrote:
> Hi all,
> RTP over TCP is unavoidable in case of RTCWeb media traffic has to traverse
> through UDP blocking firewalls. TCP candidates with ICE (RFC 6544) may fail
> due to the current OS implementation wherein TCP simultaneous Open will not
> work. 
> I have concern w.r.t TURN server as it introduces one extra network element
> for RTCWeb session establishment. The current argument favoring for TURN
> server is that RTP over TCP is required only till TURN server whereas the
> media traffic between TURN server and the destination is UDP. In couple of
> WebRTC deployment in Service provider network and Enterprise network, TURN
> server will exist near to the destination and the WebRTC media traffic in
> the internet is "RTP over TCP". I guess that Victor scenario falls under the
> same category. In these deployment, RTP over TCP has advantage over TURN
> over TCP as the extra element shall be avoided. 
> Also, SCTP over DTLS over UDP will not work in case of RTCWeb media traffic
> has to traverse through UDP blocking firewalls. So, there is a need of SCTP
> over DTLS over TCP or multipath TCP kind of transport to meet this
> requirement which needs separate discussion. 
> Thanks
> Partha
>> -----Original Message-----
>> From: [] On Behalf
>> Of Dan Wing
>> Sent: Wednesday, September 04, 2013 1:47 AM
>> To: Harald Alvestrand
>> Cc: Bernard Aboba;
>> Subject: Re: [pntaw] Real-time media over TCP
>> On Sep 3, 2013, at 11:11 AM, Harald Alvestrand <>
>> wrote:
>>> 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.
>> SCTP has been around a long time as a protocol but for a variety of
>> reasons has seen no deployment on the Internet to date, including no
>> availability in the mainstream OSs which is everyone's interest.  SCTP-
>> over-UDP was only recently defined and its user-mode release was only
>> 12 or 18 months ago or so.
>>> 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
>> f.  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.
>> -d
>> _______________________________________________
>> pntaw mailing list
> _______________________________________________
> pntaw mailing list