W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2013

Re: Discussing new API proposals

From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
Date: Wed, 17 Jul 2013 22:20:41 +0200
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>
Message-Id: <9EE1E653-C3DA-4307-9068-D3AF5476A97C@lurchi.franken.de>
To: Matthew Kaufman (SKYPE) <matthew.kaufman@skype.net>
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
> Matthew Kaufman
Received on Wednesday, 17 July 2013 20:21:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:49 UTC