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

On Tue, Jan 23, 2018 at 3:37 PM, Iñaki Baz Castillo <ibc@aliax.net> wrote:

> 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.
>

Yes, we know. I think that most productive path forward would be to support
proposals that you like, rather than continually grinding axes.

>
> 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>
>
>