Re: [pntaw] Real-time media over TCP

["Chenxin (Xin)" <[e-mail]>]

Hi

 I agree that ICE-TCP should not replace TURN as a requirement for every browser to implement. If we need support ICE-TCP , should we support TURN-TCP too? I do not think ICE-TCP will be more useful without TURN-TCP in the scenario where both browsers is under the NAT /FW which block UDP. 

  I believe the user 1->TCP->TURN server 1->UDP->TURN server 2->TCP->user 2, which Harald wrote before is workable. It is easy to tunnel the data internally if we need use the same server, right?

Best Regards,
     Xin 


>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On Behalf Of
>[e-mail]
>Sent: Thursday, October 10, 2013 1:30 AM
>To: [e-mail]; [e-mail]; [e-mail]
>Subject: Re: [pntaw] Real-time media over TCP
>
>Hi,
>
>I think the clarification is that it is not possible to initiate TCP connections from
>the "outside" of any NAT or most of the firewalls. So even if the FW does not
>block TCP per se, it only allows TCP connections to be opened from the "inside".
>
>I believe ICE-TCP will typically work only in cases where at least one of the
>endpoints is NOT behind a NAT or FW. In cases where both endpoints are behind
>firewalls completely blocking all UDP, the only option is to use a relay (TURN)
>with endpoint initiated TCP connections. ICE allows us to optimize connectivity
>in special cases, but I think we need also to make the worst case scenarios to
>work. For that reason I don't see that ICE-TCP could replace TURN as a
>requirement for every browser to implement. In some specific deployments it
>may be that TURN does not get used much or at all, but browsers are used
>everywhere.
>
>Markus
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf
>> Of ext Parthasarathi R
>> Sent: 09 October, 2013 20:01
>> To: 'Simon Perreault'; [e-mail]
>> Subject: Re: [pntaw] Real-time media over TCP
>>
>> Hi Simon,
>>
>> I have seen only two requirements in
>> draft-ietf-rtcweb-use-cases-and-requirements-11, NAT/FW that blocks UDP
>> and FW that only allows http. The relevant draft snippet is attached as a note
>> of this mail. I'm discussing about NAT/FW that blocks UDP requirement. In
>> case you foresee that the requirement is not detailed now, we need to sort
>> out the requirement first before discussion the solutions.
>>
>> Regards
>> Partha
>>
>> PS: In draft-ietf-rtcweb-use-cases-and-requirements-11 snippet,
>>
>> 3.2.2.  Simple Video Communication Service, NAT/FW that blocks UDP
>>
>> 3.2.2.1.  Description
>>
>>    This use-case is almost identical to the Simple Video Communication
>>    Service use-case (Section 3.2.1).  The difference is that one of the
>>    users is behind a NAT that blocks UDP traffic.
>>
>> 3.2.3.  Simple Video Communication Service, FW that only allows http
>>
>> 3.2.3.1.  Description
>>
>>    This use-case is almost identical to the Simple Video Communication
>>    Service use-case (Section 3.2.1).  The difference is that one of the
>>    users is behind a FW that only allows http traffic.
>>
>> > -----Original Message-----
>> > From: [e-mail] [mailto:[e-mail]] On
>> Behalf
>> > Of Simon Perreault
>> > Sent: Tuesday, October 08, 2013 11:55 PM
>> > To: [e-mail]
>> > Subject: Re: [pntaw] Real-time media over TCP
>> >
>> > Le 2013-10-08 19:52, Parthasarathi R a écrit :
>> > > I understand that two WebRTC endpoint are behind firewall scenario
>> > wherein
>> > > TURN server is unavoidable. Most of the SP & Enterprise deployment
>> > wherein
>> > > one of the endpoint is not surely going to be behind UDP blocking
>> > Firewall,
>> > > mandating TURN server as a mechanism is overkill. As ICE is mandated
>> > in
>> > > WebRTC, supporting ICE-TCP should not be such a complex activity.
>> >
>> > A firewall that blocks UDP but allows incoming TCP is not very common,
>> > is it?
>> >
>> > Or did I miss something?
>> >
>> > Simon
>> > --
>> > DTN made easy, lean, and smart --> http://postellation.viagenie.ca
>> > NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
>> > STUN/TURN server               --> http://numb.viagenie.ca
>> > _______________________________________________
>> > pntaw mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/pntaw
>>
>> _______________________________________________
>> pntaw mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/pntaw
>_______________________________________________
>pntaw mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/pntaw