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

Re: [Bug 23832] New: Requiring that negotiated channels be created on the receiver before any data can be received is problematic for some use cases

From: Martin Thomson <martin.thomson@gmail.com>
Date: Tue, 19 Nov 2013 15:37:37 -0800
Message-ID: <CABkgnnXDd4yg7hAu+cPzvMojM_xe1KC5fNiEitsUxGsvAQXV+w@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
On 18 November 2013 21:35, Harald Alvestrand <harald@alvestrand.no> wrote:
> Again, I'm searching for the justification for making the model more
> complex in order to save an OPEN message.

As I have explained before, several times, in this context, there are
usage models for SCTP that don't look like data channels.  It may be
that I just like those usage models because I'm used to them, but
here's an example that the current API doesn't support, but could
easily.

Open unreliable, out-of-order delivery stream, send packet, close
stream.  Assuming that each message provides sufficient
self-identification this is perfectly doable without an OPEN.
Requiring OPEN here would force the stream into reliable, in-order
delivery, which potentially increases the latency of the above.
Requiring signaling: even slower.  Establishing channels "just in
case": not really feasible.

Given the current API, these cases are probably better off just using
existing channels, but that suffers from concurrency issues.
Received on Tuesday, 19 November 2013 23:38:05 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:36 UTC