Re: [rtcweb] HTTP Fallback draft

Hannes Tschofenig <hannes.tschofenig@gmx.net> Tue, 07 August 2012 16:38 UTC

Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF3621F8683 for <rtcweb@ietfa.amsl.com>; Tue, 7 Aug 2012 09:38:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.615
X-Spam-Level:
X-Spam-Status: No, score=-102.615 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80UhAPWFvNLd for <rtcweb@ietfa.amsl.com>; Tue, 7 Aug 2012 09:38:56 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id E145C21F84F2 for <rtcweb@ietf.org>; Tue, 7 Aug 2012 09:38:55 -0700 (PDT)
Received: (qmail invoked by alias); 07 Aug 2012 16:38:54 -0000
Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.105]) [88.115.216.191] by mail.gmx.net (mp041) with SMTP; 07 Aug 2012 18:38:54 +0200
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX18TEmMUlbMTPg0gL8H/REJTLGh14HDAW4+NeL7g+d acDZG2Lb7j4Dzq
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
In-Reply-To: <20120807180156.286e74d2@rainpc>
Date: Tue, 07 Aug 2012 19:38:52 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <D5BDA7BE-FE55-47FA-99FD-1645084370B0@gmx.net>
References: <20120807180156.286e74d2@rainpc>
To: Lorenzo Miniero <lorenzo@meetecho.com>
X-Mailer: Apple Mail (2.1084)
X-Y-GMX-Trusted: 0
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] HTTP Fallback draft
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Aug 2012 16:38:57 -0000

Hi Lorenzo, 

working on http://tools.ietf.org/html/draft-tschofenig-hourglass-00 (and Marc on draft-blanchet-iab-internetoverport443) I am wondering about the following aspect: 

1) Do you have experience with network elements filtering RTP traffic? If so, in what networks did that happen?

2) In case you answered question #1 with 'yes' I would also like to understand why you believe that HTTP traffic will be allowed to traverse? Wouldn't you have to switch to HTTPS instead? 

Just to be clear, I don't have objections regarding your draft. I just would like to understand what motives people to run everything over HTTP (besides using HTTP features, which you don't really do). 

Ciao
Hannes

On Aug 7, 2012, at 7:01 PM, Lorenzo Miniero wrote:

> Dear all,
> 
> during the meeting in Vancouver, there was some discussion about the
> need we have for UDP-blocking firewall traversal in RTCWEB. HTTP
> fallback was mentioned, and I remember it being a matter of discussion
> at the latest interim meeting as well (at least looking at the minutes),
> even though it hasn't apparently been addressed on the ML since.
> Something in line with this was also discussed in Prague at the BOF,
> when it was clearly quite too early to address.
> 
> Someone suggested that, rather than trying to address the issue right
> away, it could be better to first try and summarize as a BCP draft what
> people already do in that respect: it's quite obvious, in fact, that
> this is already being done by many companies in their deployments, even
> though probably in a non-standard way.
> 
> Since the subject interests me (during the abovementioned IETF in Prague
> we brought a simple demo, which we used to informally showcase to a few
> interested folks the basic prototype refrlecting our research in that
> field) I chose to write a simple individual draft, instead, that rather
> than doing the summary, basically documents the first steps we did with
> our prototype. You can read the draft here:
> 
>   http://www.ietf.org/id/draft-miniero-rtcweb-http-fallback-00.txt
> 
> Please beware that it is not at all meant to be a ready-to-be-used
> solution to the problem, quite the opposite. I wrote the draft in a few
> hours and it simply addresses what we started to do to try and address
> the problem, and, as it will be obvious when reading the draft, it is
> all but complete with respect to what such a solution is supposed to
> make available: nevertheless, it tries to explain the basics of what may
> be needed, even if much more is still missing. Its purpose is rather
> trying to "throw a stone in the lake", as we like to say in Italy, in
> order to draw attention on the problem and gather potential interest by
> other people to work on it, whether or not such work would be based on
> this draft. I placed a few Editors Notes across the text on some of the
> most controversial issues, like how this should mix with ICE and
> negotiation, how easy it should be to detect it and so on. Other even
> more controversial ones, like how to address the impact of congestion
> control on real-time streams, is not in the document as of yet, but it's
> clear this will have to be taken care of eventually. Feedback and
> suggestions are more than welcome!
> 
> That said, I guess there's a different question I should be asking to
> the chairs: since there seems to be no related item in the milestones,
> is such a work actually in line with what is the expected outcome of the
> WG? Considering the draft basically addresses a new transport for RTP
> and something that probably needs to be negotiated as well, I guess this
> could be seen as belonging elsewhere (AVTCORE and/or MMUSIC?).
> Nevertheless, my feeling is it belongs more here than somewhere else,
> especially considering we're specifying a solution that will be deployed
> in browsers and, as such, people will expect it to work wherever other
> web applications do.
> 
> Thanks,
> Lorenzo
> 
> -- 
> Lorenzo Miniero, COB
> 
> Meetecho s.r.l.
> Web Conferencing and Collaboration Tools
> http://www.meetecho.com
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb