# 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:** 1\ **Showing post:** 7
**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. --- _[View the full topic](https://mediasoup.discourse.group/t/much-worse-data-channel-reliability-in-latest-mediasoup-client/5003)._