Re: [pntaw] TURN over websockets

P2P is something we can look at in the future but I don't see it as an option for enabling webrtc deployment in the near term.

We proposed the HTTP Connect mechanism in draft-hutton-rtcweb-nat-firewall-considerations because it would significantly improve the chances of enabling webrtc deployment today and requires no new implementation other than in the webrtc browser.

Regards
Andy

> -----Original Message-----
> From: pntaw-bounces@ietf.org [mailto:pntaw-bounces@ietf.org] On Behalf
> Of Marc Blanchet
> Sent: 30 August 2013 15:28
> To: Tirumaleswar Reddy (tireddy)
> Cc: pntaw@ietf.org; Sergio Garcia Murillo
> Subject: Re: [pntaw] TURN over websockets
> 
> Le 2013-08-30 à 09:53, "Tirumaleswar Reddy (tireddy)"
> <tireddy@cisco.com> a écrit :
> 
> > The other way to solve the Firewall problem is use PCP.
> 
> don't agree.  it would be great, much better design, but all the
> install base of gateways in public wifi, coffee shop wifi, hotel
> networks, etc... are not going to do any PCP.
> 
> Marc.
> 
> > For more details refer to sections 3.1, 3.2 of draft
> http://tools.ietf.org/html/draft-penno-rtcweb-pcp-00 which addresses
> the problem of Enterprise Firewalls permitting P2P media streams.
> >
> > -Tiru.
> >
> >> -----Original Message-----
> >> From: pntaw-bounces@ietf.org [mailto:pntaw-bounces@ietf.org] On
> Behalf Of
> >> Sergio Garcia Murillo
> >> Sent: Friday, August 30, 2013 2:12 PM
> >> To: pntaw@ietf.org
> >> Subject: [pntaw] TURN over websockets
> >>
> >> Hi all,
> >>
> >> I will shoot first.
> >>
> >> It is great to finally see some real interest in what I consider to
> be
> >> the blocking point for webrtc in order to run business on top of it,
> >> which is the ability to be able to connect through corporate
> firewalls.
> >>
> >> I have seen some people arguing that with just TURN over TCP on port
> 443
> >> the problem will be solved, but I seriously doubt it. Neither TURN
> over
> >> SSL would do, as most web filters do DPI and will not enable the
> >> connection. Also, I have heard lots of voices that says we are
> trying to
> >> override network admin policies with dirty tricks. With whom, I
> could agree.
> >>
> >> So, the only way I see to move forward and overcome this issues is
> by
> >> playing according to the WEB rules, and use HTTP standards to enable
> >> media connectivity in WebRTC that would play nicely with current
> >> corporate HTTP proxies and web filters.
> >>
> >> And,  for me the most viable solution would be to enable TURN over
> >> websockets. As most WebRTC services relay on websockets in one way
> or
> >> another for signaling, we could assume that media would work on 100%
> of
> >> the cases where signaling is working today.
> >> Also, as it is an http based solution, network administrators could
> >> apply corporate policies and block connections to not-trusted TURN
> servers.
> >>
> >> Best regards
> >> Sergio
> >> _______________________________________________
> >> pntaw mailing list
> >> pntaw@ietf.org
> >> https://www.ietf.org/mailman/listinfo/pntaw
> > _______________________________________________
> > pntaw mailing list
> > pntaw@ietf.org
> > https://www.ietf.org/mailman/listinfo/pntaw
> 
> _______________________________________________
> pntaw mailing list
> pntaw@ietf.org
> https://www.ietf.org/mailman/listinfo/pntaw