Re: [pntaw] Real-time media over TCP

Paul Kyzivat <> Wed, 09 October 2013 19:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C39DC21F9F50 for <>; Wed, 9 Oct 2013 12:07:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.231
X-Spam-Status: No, score=-0.231 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rovp3g3QdM+J for <>; Wed, 9 Oct 2013 12:07:00 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:43:76:96:62:16]) by (Postfix) with ESMTP id A5FC321E8194 for <>; Wed, 9 Oct 2013 12:06:31 -0700 (PDT)
Received: from ([]) by with comcast id b62Y1m0091wpRvQ5176XQh; Wed, 09 Oct 2013 19:06:31 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id b76W1m0173ZTu2S3e76WpV; Wed, 09 Oct 2013 19:06:31 +0000
Message-ID: <>
Date: Wed, 09 Oct 2013 15:06:30 -0400
From: Paul Kyzivat <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
References: <> <> <BLU405-EAS183E36A927CA42270B6936D93300@phx.gbl> <> <> <> <> <00ca01cec387$f881cae0$e98560a0$> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20121106; t=1381345591; bh=klbAUMLwN8XE4FxpV8SABVeAIvZQU0jTnIf5SUoL3Ko=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=KxyWyvFx8IiCITHAqrg4MNT3HE6SiKAAZTztYtCtFz+rmqYOL73HTMFyEV/xjlKHm zwPsSUNaOcX0Mwxt06bILFlU68YF9DmTY+GixvXZB1wbHDIKilt+pCxgQOexj/z0bs mCMfwnTjD4ggd9cfNu67AglNuTMk5rkH66ggmhBs70RTt4fHxotV7NtR7qqBNmtO2G uvCnEHOhASIJyEzVqRBCV4ls/RtK8cjVq2/JohRohHwpzmh7bwwo2NAa0hI2vl8H++ 50V8D1BrhemprqLpha3qVgHJXInbIjneG+/xLPESmkMViyYtiPGfjvPBtzDJ34oma4 vhCWsBzQlABGw==
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: Wed, 09 Oct 2013 19:07:21 -0000

On 10/9/13 1:38 PM, wrote:
> Hi Paul,
> Paul Kyzivat wrote:
>> On 10/8/13 12:32 AM, Harald Alvestrand wrote:
>>> Don't forget the (likely) case where the destination is also reached
>>> through a TURN server, so that the path is
>>> user 1->TCP->TURN server 1->UDP->TURN server 2->TCP->user 2
>>> For extra irony, the two clients may be using the same TURN service,
>>> so that the UDP hop is an intra-datacenter or even intra-machine hop
>>> :-)
>> If that happens, its time to seek out a new TURN server vendor.
>> A good one should be able to figure this out and optimize it.
> I think it can happen even if the vendor and the service provider do all they can. For instance if both endpoints are behind a UDP blocking firewall and can only open TCP connections. So unless the endpoints support TCP-based ICE candidates, I think they need to connect to their respective TURN relays and only via them they can reach each other's TURN-allocated UDP candidates. So the transport will be split into 3 hops: TCP - UDP - TCP, where the UDP part can be potentially very short.
> Or is there some way to optimize from that? If I've understood correctly, ICE-TCP with TURN-allocated TCP ports would allow using just a single relay in the above scenario. It would be thus be better in case if the relays used by the endpoints were NOT in the same DC.

My point was that if both use the *same* TURN server, then it should be 
smart enough to avoid establishing a UDP connection to itself.