Subject: [dispatch] New draft on RTCWeb Requirements and API draft-jennings-rtcweb-api

From: Cullen Jennings <[email-masked]>
Date: Thu, 10 Mar 2011 13:20:44 -0700

I wrote up the start of a draft on requirements. 

http://tools.ietf.org/html/draft-jennings-rtcweb-api-00

I think the key thing for the key thing for IETF working is starting to think about the requirements and what on the on the wire protocols are that we want to select. I included some API definition because I found it helpful to be thinking about that in this draft but that would not be part of the IETF work. That would be work I think W3C should do. The draft also touches on the of the security issues for media and signaling originating from browsers. 

Cullen

---

From: Henry Sinnreich <[email-masked]>
Date: Wed, 16 Mar 2011 13:54:39 -0500

Hi Cullen,

Section 3. Requirements says:
... In addition, there is a strong interest to define a TURN-like protocol
   that looks like HTTP to intermediaries, so that media can be tunneled
   over HTTP. 
...

This is very interesting and innovative.
Can you explain here a little bit?

Thanks, Henry

On 3/10/11 2:20 PM, "Cullen Jennings" <[email-masked]> wrote:

> I think the key thing for the key thing for IETF working is starting to think
> about the requirements and what on the on the wire protocols are that we want
> to select. I included some API definition because I found it helpful to be
> thinking about that in this draft but that would not be part of the IETF work.
> That would be work I think W3C should do. The draft also touches on the of the
> security issues for media and signaling originating from browsers.
> 
> Cullen 
> 
> 
> 
> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: Adam Roach <[email-masked]>
Date: Wed, 16 Mar 2011 14:55:22 -0500

> Can you explain here a little bit?

There's already been some work in this area. See, for example:

http://tools.ietf.org/html/rfc3093

...and...

http://msdn.microsoft.com/en-us/library/dd358571%28v=prot.10%29.aspx

(I'm becoming increasingly frustrated at the inability of creating 
parodies that last; reality keeps catching up with and then surpassing 
the level of absurdity that parody generally lives at).

/a

---

From: Lorenzo Miniero <[email-masked]>
Date: Wed, 16 Mar 2011 21:12:31 +0100

On Wed, 16 Mar 2011 13:54:39 -0500

> Can you explain here a little bit?

We implemented something like that for our system, also documented in a paper lately: basically a controller protocol that tunnels every other protocol on top of HTTP to bypass restrictive firewalls. Since it works, we were also thinking about a "lightweight" version of such protocol to only convey RTP specifically for our web interface, considering RTP is the only protocol we couldn't wrap via JavaScript so far. So I agree that such a TURN-like protocol would be a good idea for the WG.

Of course, there would be limitations and issues because of this transport, but since firewalls are there to stay, and few of them like RTP appearing "out of the blue", that's something we probably need to live with.

L.

-- 
Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools
http://www.meetecho.com

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 16 Mar 2011 14:20:37 -0700

There is already a tunneling protocol for RTP, and you cannot find more
turn-like than this: It's called TURN.  Just add an HTTP transport between the
client and the TURN server, and that's it.  I wrote an implementation (probably
4 hours of work to add this on an existing TURN server) and even an unpublished
draft of a I-D back in 2008.  The draft is probably 4 pages long without the
boilerplates (counting the Application tag for RFC 5928) - TURN is 67 pages
long, and that probably what will be needed for a "TURN-like protocol that looks
like HTTP to intermediaries".

>>> security issues for media and signaling originating from browsers.

- -- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org

---

From: Dean Willis <[email-masked]>
Date: Fri, 18 Mar 2011 22:34:06 -0500

> We implemented something like that for our system, also documented in a paper lately: basically a controller protocol that tunnels every other protocol on top of HTTP to bypass restrictive firewall…

I've recently been considering the merits of a VPN that looks like MobileIP over HTTPS over Tor. It would let one run any kind of communications traffic (albeit with odd time-domain distributions), while one would appear to be simply running HTTP traffic to various innocuous websites. The problem, of course, is that traffic that is not Web surfing has a very different time.size fingerprint, and could easily be detected. However, the approach would seem to work very well for letting people do actual Web traffic obscurely. 

If one took the Tor layer out of my idea-space, then one might get something very much like your approach. Can you share a link to your paper?

--
Dean