Re: Getting rid of SDP

Yes, I think breaking it down into something like that would make sense:
Media Source (getUserMedia), Media Encoder (a low-level encoder object),
Media Packetizer (perhaps written in JS/wasm) and RTP-based security +
MediaTransport (some low-level RtpTransport).

On Mon, Mar 5, 2018 at 6:04 PM Suhas Nandakumar (snandaku) <
snandaku@cisco.com> wrote:

> Not saying this is exactly same .. but we can think of decomposition on
> lines similar to what is defined in here :
> https://tools.ietf.org/html/rfc7656#section-2.1
>
>
>
> Sent from my iPhone
>
> On Mar 5, 2018, at 4:01 PM, Peter Thatcher <pthatcher@google.com> wrote:
>
>
>
> 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
>>>>
>>>>
>>>>
>>>>
>>>>