Re: [pntaw] Real-time media over TCP

["Parthasarathi R" <[e-mail]>]

Xin,

<snip> 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.
</snip>

Agreed. I'll write DTLS-SRTP over WebSocket draft for more clarity.  

Please read inline.

Thanks
Partha

> -----Original Message-----
> From: Chenxin (Xin) [mailto:[e-mail]]
> Sent: Friday, October 11, 2013 9:28 AM
> To: Parthasarathi R; [e-mail];
> [e-mail]; [e-mail]
> Subject: RE: [pntaw] Real-time media over TCP
> 
> 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.:)

<Partha> Thanks for the indicating the cut&paste issue :-(. Your thinking is
correct. </Partha>

> 
> 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