Hi Michael, Thanks for sharing! We recently saw this too, and my impression is similar. Ideally, from a WebRTC application's perspective, we should have a TAPS system that helps set up ICE, determines which protocol stack to use (SCTP/DTLS, SRTP, QUIC, etc), and lets the application interact with the the TAPS API regardless of the protocol.
At the very least, as an intermediate point before we go full TAPS, we should push for a model in which the API is transport independent and we use the surveys/minset of TAPS to guide the API surface. I'm adding Youenn to the thread, who is participating in the W3C WG that's discussing this. Perhaps we can give some suggestions for feedback? I think this also brings up a point that it may be good to have a discussion in Bangkok with the group about getting a bit more in detail to how TAPS can best serve WebRTC use cases, and make that aspect of the API really concrete. Thanks, Tommy > On Oct 10, 2018, at 11:20 PM, Michael Welzl <[email protected]> wrote: > > Hi, > > I just thought that it’s good for this group to be aware about this API: > https://w3c.github.io/webrtc-quic/ <https://w3c.github.io/webrtc-quic/> > > Sadly, not transport protocol independent… > > Cheers, > Michael > > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
