- From: Iñaki Baz Castillo <ibc@aliax.net>
- Date: Wed, 24 Jan 2018 00:37:22 +0100
- To: Peter Thatcher <pthatcher@google.com>
- Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
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