Re: [pntaw] Real-time media over TCP

[Paul Kyzivat <[e-mail]>]

On 10/9/13 1:38 PM, [e-mail] 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.

	Thanks,
	Paul