W3C home > Mailing lists > Public > public-webrtc@w3.org > January 2018

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

From: Justin Uberti <juberti@google.com>
Date: Tue, 23 Jan 2018 22:57:01 -0800
Message-ID: <CAOJ7v-3L-tKZ2dQC_w3NJ57OJNy-qEMDaYwDcx3TO9uRfgA8_w@mail.gmail.com>
To: Iñaki Baz Castillo <ibc@aliax.net>
Cc: Peter Thatcher <pthatcher@google.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
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>
Received on Wednesday, 24 January 2018 06:57:48 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 24 January 2018 06:57:50 UTC