- From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
- Date: Wed, 17 Jul 2013 22:20:41 +0200
- To: Matthew Kaufman (SKYPE) <matthew.kaufman@skype.net>
- Cc: cowwoc <cowwoc@bbs.darktech.org>, "piranna@gmail.com" <piranna@gmail.com>, public-webrtc <public-webrtc@w3.org>, Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
On Jul 17, 2013, at 8:55 PM, Matthew Kaufman (SKYPE) <matthew.kaufman@skype.net> wrote: > From: cowwoc [mailto:cowwoc@bbs.darktech.org] : > > I just want to point out that you are mentioning two separate things here: > 1. Complexity of API: Leading to resistance by end-users. > 2. Complexity of implementation: Leading to resistance by implementors/integrators. > I have not heard of #2, though maybe that is because public-webrtc discussions are limited to #1. > > As a browser vendor, I can tell you that putting a complete SDP offer/answer state machine inside a browser and making it compatible with the undocumented idiosyncrasies of the other browser vendors is even more difficult than getting an SCTP-over-DTLS stack in the layer of the OS where it would need to live in order to be compatible with how certain browsers are architected. But both are a problem. Are you considering to put SCTP-over-DTLS in the OS kernel? This would mean to have DTLS in the kernel... I have seen SCTP in the kernel, DTLS in userland (which results in typical DTLS over SCTP stacks) and SCTP and DTLS in userland... Best regards Michael > > Matthew Kaufman > >
Received on Wednesday, 17 July 2013 20:21:07 UTC