Re: [pntaw] Real-time media over TCP

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

Hi
>Hi all,
>
>As I mentioned below, ICE-TCP is not replacement for TURN but ICE-TCP helps
>for the browser-to-browser media flow without middle box (TURN Server).
>Also, please note that both browsers behind UDP blocked firewall is not the
>worst case scenario for WebRTC firewall requirements. The actual worst case
>scenario is that both browsers are behind HTTP only firewalls and in this
>scenario, both TURN server and ICE-TCP will not work. There is a need of one
>more solution.
>
>AFAIK, HTTP allowing firewall is not happen by mis-configuration but it is
>policy of the given network. It is more appropriate to pass the media over
>HTTP based mechanism rather than finding the workarounds. The advantage
>with
>Media over HTTP is that HTTP friendly firewall shall filter out media from
>HTTP traffic if required.
[xin] And media over websocket should be a option. The sub-protocol attribute in websokcet could also provide the firewall friendly information, so the firewall could decide to filter out the media or not. 

 IMO, Media over HTTP based mechanism has to be
>used for HTTP only firewall (Sec 3.2.3 of
>draft-ietf-rtcweb-use-cases-and-requirements) requirement and ICE-TCP shall
>be used for (Sec 3.2.3 of draft-ietf-rtcweb-use-cases-and-requirements)
>requirement.

  [Xin] I think you means ICE-TCP shall be used for (*Sec 3.2.2* of draft-ietf-rtcweb-use-cases-and-requirements) requirement.:)

Thanks,
  Xin
>
>Thanks
>Partha
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf
>> Of Chenxin (Xin)
>> Sent: Thursday, October 10, 2013 7:23 AM
>> To: [e-mail]; [e-mail];
>> [e-mail]; [e-mail]
>> Subject: Re: [pntaw] Real-time media over TCP
>>
>> 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
>> _______________________________________________
>> pntaw mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/pntaw