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

On 24/01/18 00:40, Iñaki Baz Castillo 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.
> 
> 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".

The current (soon expiring) charter has some text on starting new work 
once WebRTC 1.0 is at CR (which it by now is). In the charter it is said 
that one of the principles that will be adhered to in the new work is:

"Direct control: The new APIs are intended to provide direct control 
over the details of real-time communication, where the application can 
directly specify how information should be transmitted, without any 
built-in negotiation semantics."

I read "without any built-in negotiation semantics" as meaning there 
should be no SDP O/A.

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

Received on Wednesday, 24 January 2018 10:16:22 UTC