- From: Lennart Grahl <lennart.grahl@gmail.com>
- Date: Mon, 5 Mar 2018 23:40:10 +0100
- To: WebRTC WG <public-webrtc@w3.org>
- Cc: Cullen Jennings <fluffy@iii.ca>, Peter Thatcher <pthatcher@google.com>, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
On 05.03.2018 23:20, Cullen Jennings wrote: >> On Mar 5, 2018, at 2:57 PM, Lennart Grahl <lennart.grahl@gmail.com> wrote: >> >>> >>> Let's define a low level modular api (that is what most devs want >>> anyway) that could be reused in different scenarios (ICE+DTLS+ICE or >>> quick) easily. >> >> Isn't that what ORTC does provide? > > So ORTC does a good job of what it does, which is get rid of the syntax of SDP and provide a programmatic interface to an RTP media stack that is roughly capable of what can be done with SDP Offer/Answer. As a result, most of ORTC 1:1 maps to the semantics or SDP. > > Take something simple like ptime and maxptime in ORTC. To real understand what these are and how they fit into RTP, what they do in an offer/answer, etc, you will be reading SDP documents. The approach in new-media is to ask if we could get rid of tons of the baggage that has accumulated in RTP, solve a bunch of the features that are too hard to do in existing RTP/ICE, and simplify the RTP in a huge way that allowed us to move to something with far simpler semantics that SDP. Fair enough. Having read Peter's and Sergio's answers as well, it seems using ORTC as a starting point is a good idea and extending it with more fine granular control or entirely new "building blocks" (objects). Peter, can you send me a link to the SLICE spec/slides? (https://w3c.github.io/webrtc-ice does look way too high level to me) Cheers Lennart
Received on Monday, 5 March 2018 22:40:33 UTC