Subject: Re: [rtcweb] Comments on draft-miniero-rtcweb-http-fallback

From: Lorenzo Miniero <[email-masked]>
Date: Thu, 18 Oct 2012 19:30:59 +0200

Martin,

it looks like you missed this:

http://www.ietf.org/mail-archive/web/rtcweb/current/msg05035.html 

The draft was not at all meant as a proposed solution (as "grossly inefficient" as it is), but just as a way to poll for interest about work in that direction in the group, and discuss whether or not something like that would be needed in first place.

Feel free to take it from there and revive the discussion, if needed.

Lorenzo

Martin Thomson <[email-masked]> ha scritto:

>This seems grossly inefficient.  Even if you assume that we have to
>tolerate the head-of-line blocking properties of a stream transport,
>the overhead of HTTP headers is immense.
>
>What is wrong with WebSockets for this use case?
>
>Why is there so much discussion on topology?  It seems that the
>topology used for TURN is perfectly good and would require the least
>disruption.
>_______________________________________________
>rtcweb mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Martin Thomson <[email-masked]>
Date: Thu, 18 Oct 2012 10:47:41 -0700

> http://www.ietf.org/mail-archive/web/rtcweb/current/msg05035.html

I remember reading that, but considered that starting a new thread was
appropriate, that's all.

My view on the subject is that firewall circumvention is not and
should not be the goal of any such work.  A proper approach would be
to use a TURN server that manages access control in a transparent
fashion.

That said, firewalls often block UDP for reasons other than a deep and
abiding hatred of VoIP.  Those firewalls are probably not doing
anything that would prevent something like WebSockets from working.
In those environments, a standard method for using the available
communication channels could be helpful.  WebSockets is also far more
efficient with its use of bits.  Hence, WebSockets.

The main objection to something like WebSockets is that some
environments actively block WebSockets.  These firewalls often block
HTTPS in the same way.  In that case, I see no reason to continue to
build ever more elaborate circumvention methods.

I've said enough.  I just realized that this is not really an rtcweb
topic.  (behave?)

---

From: Salvatore Loreto <[email-masked]>
Date: Fri, 19 Oct 2012 10:17:52 +0300

On 10/18/12 8:47 PM, Martin Thomson wrote:
> HTTPS in the same way.
that is interesting,
I have heard a lot people saying that usually the firewalls
(well some time they talk of the proxy really more then firewall)
are more likely to block WebSocket then HTTP

and they use that statement to promote an HTTP fallback
(here I am talking in general not specifically for webrtc)

However if we are talking of secure WebSocket and https fallback
I agree that if a firewall block secure Websocket then it will most 
likely block
HTTP as well !

>   In that case, I see no reason to continue to
then I tend to agree in not trying to define a fallback of the fallback
> I've said enough.  I just realized that this is not really an rtcweb
I would say that is rtcweb until we do not define what we want to do

ciao
Salvatore

-- 
Salvatore Loreto, PhD
www.sloreto.com