- From: youenn fablet <yfablet@apple.com>
- Date: Mon, 05 Mar 2018 15:42:35 -0800
- To: Peter Thatcher <pthatcher@google.com>
- Cc: "Cullen Jennings (fluffy)" <fluffy@cisco.com>, WebRTC WG <public-webrtc@w3.org>
- Message-id: <10949883-DCC9-477B-95D4-210935C8B61D@apple.com>
> If you want to send media over QUIC or do your own crypto between encode and network (perhaps over some low-level RTP transport), then you need access to media after its encoded and before it's decoded. I am not opposed to exposing capabilities of the platform to web pages, I just want to make sure we do that in the right order. If what is just missing for PERC-like scenarios is this encoder/decoder API, that would raise the priority to me. It seems though that this API might require additional APIS to being really useful (I probably need to read your presentation first). Also, to be clear, exposing decoders/encoders that the platform supports seems good to me as a principle. On the other hand, allowing web pages to provide their own JS/WASM encoders/decoders would require compelling scenarios that are not feasible otherwise. I have not heard yet at any such scenario (again I might need to read your presentation first). Thanks for your efforts in moving this forward, Y > Maybe I should look at what was presented at TPAC but I would tend to put it at a much lower priority. > > Here's what I presented: > > https://docs.google.com/presentation/d/1Sg_1TVCcKJvZ8Egz5oa0CP01TC2rNdv9HVu7W38Y4zA/edit#slide=id.g29a8672e18_22_120 <https://docs.google.com/presentation/d/1Sg_1TVCcKJvZ8Egz5oa0CP01TC2rNdv9HVu7W38Y4zA/edit#slide=id.g29a8672e18_22_120> > > > > >> I think having those APIs available for your idea to be possible to implement in a web context (or other similar ideas) is a great direction to go. >> >> >> The only thing I think your proposal seeks that the three APIs above cannot provide is a mechanism for replacing the STUN/TURN message format. It could allow for new STUN/TURN message formats if run over QUIC, but if they need to be outside of QUIC, then it would need be standardized first in the IETF and then added into SLICE. >> >> On Mon, Mar 5, 2018 at 11:48 AM Cullen Jennings (fluffy) <fluffy@cisco.com <mailto:fluffy@cisco.com>> wrote: >> >> SDP is really awful - encoding SDP as parsed JSON does not help much. What we need to do to greatly simplify things is get rid of SDP. The offer answer is really complicated for modern systems that have more uniform capabilities so I would like to get rid of offer answer too. To simplify all the control, I think one needs to also simplify STUN, TURN, ICE, RTP, and SRTP. >> >> I wrote a draft outlining that - it is at: >> >> https://datatracker.ietf.org/doc/draft-jennings-dispatch-new-media/ <https://datatracker.ietf.org/doc/draft-jennings-dispatch-new-media/> >> >> it is being discussed on the dispatch@ietf.org <mailto:dispatch@ietf.org> email list ( you can join at https://www.ietf.org/mailman/listinfo/dispatch <https://www.ietf.org/mailman/listinfo/dispatch>). Glad to get PR at https://github.com/WhatIETF/draft-jennings-dispatch-new-media <https://github.com/WhatIETF/draft-jennings-dispatch-new-media> >> >> Love to get feedback in general and also on how this, or parts of it, would be a good way to go for the next version of WebRTC >> >> Thanks, Cullen >> >> >> >>
Received on Monday, 5 March 2018 23:42:59 UTC