[rtcweb] Possible to lose initial messages sent by reliable, out-of-band negotiated data channels

[Taylor Brandstetter <[e-mail]>]

One might expect that a "reliable" data channel is guaranteed to be, well,
reliable. But in current implementations, the first messages may be lost if
the application is negotiating the channels out-of-band, and creates the
receiving channel too late.

Here's a fiddle that demonstrates this (happens with Chrome and Firefox):
https://jsfiddle.net/o2m8tp20/

Normally this isn't an issue, because a typical application would create
the out-of-band negotiated channels before the first offer/answer is
complete, and thus before the SCTP association is established. Meaning that
by the time a data channel is "open", it's guaranteed that the other peer
has a corresponding channel.

But if for whatever reason, an application creates a data channel *after*
the SCTP association is established, then it will instantly be "open" as
soon as it's created. If a message is sent at this point, and it's received
by the other peer before it's created its corresponding data channel, then
the message will just be discarded.

So, how should we deal with this? Some possibilities:

   1. Say "this is expected behavior" and document it better, breaking the
   reliability promise.
   2. Run the closing procedure if a message is received on a stream before
   a data channel is ready to receive it.
   3. Don't even allow an out-of-band negotiated channel to be created
   after the SCTP association is established.
   4. Buffer these messages for up to X seconds (or up to X bytes), to be
   delivered to the data channel once it's created. Run the closing procedure
   if X is exceeded.

I'd vote for #2. Adding additional buffering logic seems like overkill if
this isn't a use case we really intended to support.

Corresponding webrtc-pc issue: https://github.com/w3c/webrtc-pc/issues/1879