[webrtc-pc] Possible to lose data with a reliable, pre-negotiated data channel?

taylor-b has just created a new issue for https://github.com/w3c/webrtc-pc:

== Possible to lose data with a reliable, pre-negotiated data channel? ==
One might expect that a "reliable" data channel (the default behavior, where `maxRetransmits` and `maxPacketLifeTime` are left unset) 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 (setting `negotiated` to `true`), and creates the receiving channel too late.

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

Normally, the sequence is something like:

1. Offerer creates channel.
2. Sends offer.
3. Answerer receives offer, creates channel.
4. Sends answer.
5. SCTP handshake completes, channels become open and start sending data.

But if the SCTP handshake is already complete when one side creates a new channel (or the other side just creates its channel too late), then the channel may be "open" before the other's is even created. So when usrsctp receives a message and delivers a message to the WebRTC stack there's no data channel to deliver it to, and it's just dropped.

Is this expected behavior? Or should implementations be buffering this data until the channel is created? If it's expected behavior, the spec should clarify this somewhere.

Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1879 using your GitHub account

Received on Friday, 25 May 2018 17:25:29 UTC