Re: What would you like to see in WebRTC next? A low-level API?

On 23 January 2018 at 23:55, Peter Thatcher <pthatcher@google.com> wrote:
> What do we want to accomplish with WebRTC next, and how are we going to get there?

This is just a preliminary response since I expect to provide a more
detailed one.

I don't know which exact additions I'd like to see in WebRTC NG
(although those in your initial email look really nice) but I do know
what I do NOT want to see in WebRTC NG:

SDP.

Honestly, I've lost interest in the spec due to the infamous time
spent on SDP related stuff. I just cannot stand with so many email
threads, drafts, proposals and GitHub issues regarding "transceiver",
"direction" attribute in the m-line, the a=msid hack, the ugly remote
track.id value in the SDP, the transceiver.receiver.track
automatically created without having any real remote track at all
(just because `track` is non nullable in RTCRtpReceiver and `receiver`
is non nullable in RTCTransceiver), nor I can stand with so many
discussions about BUNDLE and the issues if a m-line does not provide
ICE candidates and it's not in the BUNDLE a=group, or peerconnections
closing the ICE+DTLS when there are no active send/recv streams just
because SDP was designed that way 20 years ago.

It's 2018 and people in the rtcweb WG is still discussing (or
re-defining) how codecs are negotiated and re-negotiated in the SDP
O/A protocol. Really?

Also, I want an API that lets me know what happens *in context*,
meaning that I don't want to rely on contextless "events" fired after
calling an API call such as setRemoteDescription(). I don't want to
receive a blob via my custom signaling, pass such a blob to the WebRTC
API and then wait for events, events that are hard to correlate with
extra information received via sig.  And I don't want to do magic to
associate each remote stream/track with the appropriate "user" by
"parsing" the SDP in local or remote side or similar hacks.

More about this here: https://webrtchacks.com/webrtc-sdp-inaki-baz-castillo/


If we really want to make WebRTC useful for developers other than
browser vendors and C++ experts, we cannot transmit a SDP blob as the
"minimum irreducible unit for exchanging multimedia information".

WebRTC NG must come with a real low level RTC API, and ORTC is a good
place to start (or continue).


PS: And I want a W3 spec that conforms to a normal W3 spec (rather
than being splitted into a W3 spec plus a IETF spec, JSEP, both
describing how the RTCPeerConnection API works).


-- 
Iñaki Baz Castillo
<ibc@aliax.net>

Received on Tuesday, 23 January 2018 23:38:09 UTC