- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Tue, 19 Nov 2013 15:37:37 -0800
- 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