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

[Cullen Jennings <[e-mail]>]

Can the browser take care of it from what it knows about setting up the channel? 

> On Jun 13, 2018, at 4:48 PM, Taylor Brandstetter <[e-mail]> wrote:
> 
> It sounds like you and Christer are suggesting the same thing: "don't allow messages to be sent until you're sure the other peer has a channel to receive them". Except that there's no way for the WebRTC stack to know that, since these channels are not signaled in SDP or any in-band message.
> 
> On Wed, Jun 13, 2018 at 1:32 PM, Cullen Jennings <[e-mail] <mailto:[e-mail]>> wrote:
> 
> 
>> On May 31, 2018, at 12:24 PM, Taylor Brandstetter <deadbeef=[e-mail] <mailto:deadbeef=[e-mail]>> wrote:
>> 
>> 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/ <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:
>> Say "this is expected behavior" and document it better, breaking the reliability promise.
>> Run the closing procedure if a message is received on a stream before a data channel is ready to receive it.
>> Don't even allow an out-of-band negotiated channel to be created after the SCTP association is established.
>> 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.
> 
> I lean toward something that just did not allow the  out-of-band channel negotiation be used until it was set up.
> 
> But whatever we do, not option 1 
> 
> 
> 
> 
> 
>  
> 
> 
> 
> 
> 
>