- From: Peter Thatcher <pthatcher@google.com>
- Date: Mon, 05 Mar 2018 23:56:58 +0000
- To: youenn fablet <yfablet@apple.com>
- Cc: "Cullen Jennings (fluffy)" <fluffy@cisco.com>, WebRTC WG <public-webrtc@w3.org>
- Message-ID: <CAJrXDUH-d-4Vrk91zwf9BO3gAaBDqW9RwtVYu3QjFYRJhf1OGQ@mail.gmail.com>
On Mon, Mar 5, 2018 at 3:42 PM youenn fablet <yfablet@apple.com> wrote: > 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. > I think breaking up the RtpSender into encoder and RtpTransport such that you could inject your own encryption stage in between is a good way to go about it. > 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 > > > >> 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> 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/ >>> >>> it is being discussed on the dispatch@ietf.org email list ( you can >>> join at https://www.ietf.org/mailman/listinfo/dispatch). Glad to get PR >>> at 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:57:35 UTC