- From: <bugzilla@jessica.w3.org>
- Date: Mon, 19 Dec 2011 17:06:41 +0000
- To: public-webrtc@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15206 Randell Jesup <rjesup@jesup.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rjesup@jesup.org --- Comment #2 from Randell Jesup <rjesup@jesup.org> 2011-12-19 17:06:39 UTC --- There's an extensive discussion on this point starting on Nov 15 2011 on the rtcweb mailing list (started by me), under the title "Data channel setup and signalling". http://www.ietf.org/mail-archive/web/rtcweb/current/msg02861.html Summary: I propose that (some) data channels be opened without use of offer-answer signaling, based on the application, perhaps using a data channel initially set up to let the application request data channels using application-specific messages. In particular, applications should be allowed to avoid a re-negotiation of all channels to open data channels, when the application knows it's talking to another copy of itself (or equivalent). This proposal mostly covered the IETF side of things; how these would be exposed to the JS app is something I hadn't answered and would enjoy suggestions on. Quoting one bit to highlight: A use-case would be a background http proxy-server during chat. If you have to re-OFFER for each data channel that comes and goes to transfer a resource, it will both swamp the server and be slow (due to the triangle signalling). If instead the application can open a single control data channel, and invoke transfers over it, the application can efficiently transfer a high number of URIs. Are there other ways to do this without re-OFFERing constantly? yes. But they generally involve building protocols on top of an array of long-lasting generic connections. For example, the control data channel might pass messages (directly browser-to-browser) like { id: 1, command: "GET", URI: "blah/foo/bar", channel: 5, } with an answer: { id: 1, result: "ok", size: 1234, } followed by transfer of the URI on data channel 5. (Note: in this I'm assuming an API that lets the app open a specific data channel of the peer connection.) -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. You are the assignee for the bug.
Received on Monday, 19 December 2011 17:06:46 UTC