Re: [pntaw] Real-time media over TCP

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 
MUSTs for RTCWEB.

>
> On Sep 2, 2013, at 1:37 AM, "Harald Alvestrand" <harald@alvestrand.no> 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
>> pntaw@ietf.org
>> https://www.ietf.org/mailman/listinfo/pntaw