# Much worse data channel reliability in latest mediasoup-client **URL:** \ **Category:** mediasoup libraries\ **Created:** [March 1, 2023, 10:36am UTC](https://mediasoup.discourse.group/t/much-worse-data-channel-reliability-in-latest-mediasoup-client/5003 "2023-03-01T10:36:09Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![jure](https://avatars.discourse-cdn.com/v4/letter/j/df705f/32.png) [@jure](https://mediasoup.discourse.group/u/jure)\ **Post date:** [March 1, 2023, 10:36am UTC](https://mediasoup.discourse.group/t/much-worse-data-channel-reliability-in-latest-mediasoup-client/5003/1 "2023-03-01T10:36:09Z")
Hi! We’ve found ourselves upgrading from `mediasoup-client` 3.6.57 to 3.6.80 recently, and while we didn’t notice anything wrong immediately, the reliability of our data channel connections became a lot worse. At first we thought some of our other code changes impacted this, but when we reverted only the `mediasoup-client` upgrade, reliability returned to baseline. We have thousands of data channel connections daily, so the change is definitely statistically significant. I’ve attached a screenshot of our data channels failed vs data channels opened chart, expressed in %, with times of upgrades/reverts annotated too - in summary, the failure rate went from 0-5% to 10-30%. Do you have any thoughts on what changes in client could have caused this? I thought it would be good to ask, as we unfortunately do not yet have an isolated reproduction. We will continue digging, however. Thank you for your help! ![Screenshot 2023-03-01 at 11.27.42](https://global.discourse-cdn.com/free1/uploads/mediasoup/original/2X/f/f9eb893e1966c3496191f1973eae780b777e1562.png) ---
**Author:** ![ibc](https://yyz2.discourse-cdn.com/free1/user_avatar/mediasoup.discourse.group/ibc/32/1540_2.png) [@ibc](https://mediasoup.discourse.group/u/ibc)\ **Post date:** [March 1, 2023, 1:20pm UTC](https://mediasoup.discourse.group/t/much-worse-data-channel-reliability-in-latest-mediasoup-client/5003/2 "2023-03-01T13:20:41Z")
I fail to see how mediasoup-client version can affect reliability of data channel. It’s just a wrapper when it comes to DataChannel API. Which `handler` are you using? Chrome74 or Chrome111? ---
**Author:** ![jure](https://avatars.discourse-cdn.com/v4/letter/j/df705f/32.png) [@jure](https://mediasoup.discourse.group/u/jure)\ **Post date:** [March 1, 2023, 2:53pm UTC](https://mediasoup.discourse.group/t/much-worse-data-channel-reliability-in-latest-mediasoup-client/5003/3 "2023-03-01T14:53:17Z")
We’re as surprised as you are. We’re using `new Device()` without supplying a specific handler, so leaving it up to the auto-detect. That would mean that when we switched from 3.6.57 to 3.6.80 the handler also switched? But given that almost nobody is on Chrome 111 yet, the auto-detected handler would likely remain Chrome 74 in most cases. ---
**Author:** ![ibc](https://yyz2.discourse-cdn.com/free1/user_avatar/mediasoup.discourse.group/ibc/32/1540_2.png) [@ibc](https://mediasoup.discourse.group/u/ibc)\ **Post date:** [March 1, 2023, 3:08pm UTC](https://mediasoup.discourse.group/t/much-worse-data-channel-reliability-in-latest-mediasoup-client/5003/4 "2023-03-01T15:08:15Z")
device.handlerName will tell you which handler it chose. It’s basically impossible that your problem is related to mediasoup-client version, specially if same Chrome74 handler is being used. ---
**Author:** ![snnz](https://yyz2.discourse-cdn.com/free1/user_avatar/mediasoup.discourse.group/snnz/32/693_2.png) [@snnz](https://mediasoup.discourse.group/u/snnz)\ **Post date:** [March 1, 2023, 4:10pm UTC](https://mediasoup.discourse.group/t/much-worse-data-channel-reliability-in-latest-mediasoup-client/5003/5 "2023-03-01T16:10:39Z")
The legend on the chart says “count(Producer transport failed)”, and what exactly “transport failed” means? That the transport (i.e. peer connection) entered a failed state? But this is not necessarily related to data channels. More specific statistics distingushing different kind of failures is needed to understand the problem. ---
**Author:** ![jure](https://avatars.discourse-cdn.com/v4/letter/j/df705f/32.png) [@jure](https://mediasoup.discourse.group/u/jure)\ **Post date:** [March 1, 2023, 9:23pm UTC](https://mediasoup.discourse.group/t/much-worse-data-channel-reliability-in-latest-mediasoup-client/5003/6 "2023-03-01T21:23:28Z")
What I posted is a graph of `count("Producer transport state: failed")` divided by `count("Producer transport state: connected")`, both of which are logged `.on("connectionstatechange")` for our producers. You’re right, what we’re looking at here specifically is the WebRTC producer transport state, not just the associated data channels, but the effects for us were mostly visible in various data channel related features failing, thus the title. Apologies! Same reliability change occurred for our consumer transports as well. Interestingly, plotting the `disconnected` vs `connected` state displays no such change. So it looks like more disconnects now go into the failed mode. And indeed plotting `failed` vs `disconnected` does clearly reveal that. We will dig a bit deeper and return with more data! ---
**Author:** ![jure](https://avatars.discourse-cdn.com/v4/letter/j/df705f/32.png) [@jure](https://mediasoup.discourse.group/u/jure)\ **Post date:** [March 5, 2023, 11:05pm UTC](https://mediasoup.discourse.group/t/much-worse-data-channel-reliability-in-latest-mediasoup-client/5003/7 "2023-03-05T23:05:39Z")
Turns out it’s a bit more complicated, or less complicated, depending on one’s viewpoint. Basically our perception of transport reliability was impacted by this change: [Handle pc.connectionState (when supported) instead of pc.iceConnectio… · versatica/mediasoup-client@3134822 · GitHub](https://github.com/versatica/mediasoup-client/commit/3134822a5f314a315db977e4e834425bfae7698f) So in other words while the underlying reliability of our transports has remained the same in 3.6.80 (vs 3.6.57), we now get a lot more “failed” states, which is what we use to signal to our users that their connections has been disrupted. So users complained, since they saw many more network notifications etc. The other side of the coin is worse, however, in that we’ve not been telling Chrome users that their connection has “failed” even when it did die, because we were not aware of it, as the state was “disconnected”. So the updated version is great, causing us to come to terms with how unreliable these connections can be over the longer term (we get a 10-20% failure rate over say 20-30 minutes, which seems quite high, but I don’t have external data to compare it to - is it high?). As a result of these findings, we’re now implementing connection rescue and proper reconnection mechanisms, as well as digging into transport reliability. Some more very relevant discussions on this topic for anyone who stumbles across this in the future: > [@Transport connectionstate never changes to 'failed', stuck on 'disconnected'](https://mediasoup.discourse.group/t/transport-connectionstate-never-changes-to-failed-stuck-on-disconnected/4125): > > I am working on re-connectivity during the call to connect user back to call if peer connection failed because of network conditions. The issue is during the call when I turn off network then transport connection state changes to ‘disconnected’ but never goes to ‘failed’ state. I have checked the underlying peer connection using chrome://webrtc-internal, it correctly goes to failed state after disconnected state. Can you please guide me what can be the issue? Also I was able to access origin… > > > \## Bug Report > > Hi, > > From the \[documentation\](https://mediasoup.org/documenta…tion/v3/mediasoup-client/api/#transport-on-connectionstatechange), \`transport.on(“connectionstatechange”, fn(connectionState)\`, emits \`RTCPeerConnectionState\`. However, mediasoup-client internally listens and emits \`RTCIceConnectionState\`. > > \### Your environment > > \- Operating system: MacOS > \- Browser version: Chrome 108 > \- npm version: 7.24 > \- mediasoup version: 3.11.3 > \- mediasoup-client version: 3.6.57 > > > \### Issue description > > The issue with this comes during disconnection. Suppose, you turn off the internet, \`connectionstatechange\` goes from \`connected\` -\> \`disconnect\` and there's still a chance that the connection can go \`connected\` again (there's a 10-second window for the next retry). If the retry is unsuccessful, \`RTCPeerConnectionState\` emits \`failed\` event whereas \`RTCIceConnectionState\` is still in \`disconnect\` state so transport never emits the \`failed\` event. > For ice restarts, I'm waiting for this \`failed\` state, rather than \`disconnect\` state because of the auto retry. > Now, since mediasoup-client only emits \`RTCIceConnectionState\` on transport, I have to internally listen to this private state via \`transport.handler.\_pc.connectionState\` to find out if the actual connection state and then do an ice restart. > > This is mediasoup-client code related to this: > \`\`\` > // Listens to RTCIceConnectionState and not RTCPeerConnectionState > this.\_pc.addEventListener('iceconnectionstatechange', () =\> { > switch (this.\_pc.iceConnectionState) { > case 'checking': > this.emit('@connectionstatechange', 'connecting'); > break; > case 'connected': > case 'completed': > this.emit('@connectionstatechange', 'connected'); > break; > case 'failed': > this.emit('@connectionstatechange', 'failed'); > break; > case 'disconnected': > this.emit('@connectionstatechange', 'disconnected'); > break; > case 'closed': > this.emit('@connectionstatechange', 'closed'); > break; > } > }); > \`\`\` > > > Wanted to know if this is intentional. If so, then the documentation should reflect the actually used state. Having the transport emit the \`RTCPeerConnectionState\` would be useful for the above case mentioned instead of listening on the \`RTCPeerConnection\` object itself. ---
**Author:** ![zaidiqbal](https://yyz2.discourse-cdn.com/free1/user_avatar/mediasoup.discourse.group/zaidiqbal/32/1498_2.png) [@zaidiqbal](https://mediasoup.discourse.group/u/zaidiqbal)\ **Post date:** [March 6, 2023, 7:24am UTC](https://mediasoup.discourse.group/t/much-worse-data-channel-reliability-in-latest-mediasoup-client/5003/8 "2023-03-06T07:24:43Z")
I see so this issue of connectionstate stuck at disconnected and not going to failed state is fixed in this new version, that is great.