Improve and verification

[Didi3333]

Hi,

In case of multiUser can you add in return of onNetworkScoresUpdated the ID of the peerconnection, like that we can identify who as a bad connectivity.

In addition, is it possible to separate in return the score obtain by video and the one of audio

Furthermore regarding the MOS itself, whren i initiate a classic audio in my laptop between two browser ( Chrome and Edge), i have the following result:

And i don't understand what i am not closer as 5

And a last question, when you parse each rtcStats in RTCStatsParser.ts, i think you don't check if tracks retrun by getSenders or getReceivers are still alive => track.readyState ==="live"

const receiversStats = await Promise.all(pc.getReceivers().map((r) => r.getStats()));
const sendersStats = await Promise.all(pc.getSenders().map((r) => r.getStats()));

Regards ;)

[desher]

Hello @Didi3333
Thank you for bringing these issues to our attention.

In case of multiUser can you add in return of onNetworkScoresUpdated the ID of the peerconnection, like that we can identify who as a bad connectivity.

You can follow PR #21. This is exactly what you needed.

In addition, is it possible to separate in return the score obtain by video and the one of audio

Bad network conditions or high CPU load usually affect both of track types. That's why we don't not separate scores by track types.

And i don't understand what i am not closer as 5

I'm going to review MOS calculation and make some fixes. I've noticed that during a very poor network (rtt > 10s) the score can take values out of range 0-5.

And a last question, when you parse each rtcStats in RTCStatsParser.ts, i think you don't check if tracks retrun by getSenders or getReceivers are still alive => track.readyState ==="live"

Thank you. Noted. Will check and come back with PR.