[rtcweb] HTTP Fallback draft

[Lorenzo Miniero <[e-mail]>]

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