> On 11 Oct 2018, at 23:14, Tommy Pauly <[email protected]> wrote:
>
> 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 agree - also, it seems to me that the original WebRTC API was more abstract,
starting with the concept of channels and such...
> 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.
To me, that seems like a very good suggestion!
Cheers,
Michael
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
