I reported this previously as Bytes are transferred but no real audio stream is received and it is still happening (rarely) in my production and users are complaining about random failure in audio subscriptions. I’m wondering how can I trace the issue while I’m not able to reproduce it.
Did you actually follow this?
I believe I am and it’s working well for 99 percent of the time. However I can log the rtpCapabilities received from the client (web browser) if it’s the thing that I should be concerned about.
No, that won’t help. You may try by forcing Chrome67 handler in your mediasoup-client apps (just when the browser is Chrome of course) which uses PlanB and see if the problem does not happen. However it’s super hard to figure out where the issue may be.
BTW maybe you are trying to render remote audio before getUserMedia with audio succeed? If so some of your clients may run into the browser auto-play policy issues.
Then do you have any idea how to detect if the problem is solved? My only source at the moment is user feedbacks! Would checking data in the rtp trace event help?
I’ve handled the auto-play policy however it shouldn’t affect the received RTP stream and RTC stats, right?
No, I have no idea if the problem has been solved. I don’t know if this is a problem in mediasoup or in your code. I’ve just never seen it.
I suggested something but you seem to propose other checks. No, those won’t work. If you receive RTP in the browser but it does not produce audio, the issue won’t be detected by checking the stats or trace event which will just confirm you that the browser is receiving RTP packets.
However you can check the browser stats and check whether there are decided bytes or not for that incoming audio track.
I’ll try your suggestion of course but before that I think I need a way to detect the issue. Then I can log when it happens and maybe I can find a particular scenario for that.
Good idea 
.
For that I need to collect user stats/logs some where for later analysis.
We have similar reports from users, that are so sporadic it is difficult to reproduce @mkh what versions do you use?
The version is irrelevant. Let’s please focus on this:
1 Like
I could reproduce the issue. It does not happen with Chrome67 handler (as you advised 
). Firefox is fine too.
Is it safe to force Chrome67 in production until the issue is fixed? How about users with chrome < 67?
BTW there is mistype in the docs I couldn’t find in github repo to submit pr:
const device = new mediasoupClient.Device({ handlerName: "Chrome67" });
Fix:
const device = new mediasoupClient.Device({ Handler: "Chrome67" });
No, it’s ok. The change was announced here.
Which exact issue?
What change are you talking about?
The issue that the topic has been created for: No audio is heard but RTP data is received.
It was not announced as I thought, sorry. BTW the API docs follow the latest version. Probably you are not using it so you still need to use previous syntax.
Yes, the issue. Not sure how to fix something that I’ve never experimented without any way to reproduce it not specific details about what’s wrong. I’m afraid the issue won’t be fixed automagically.
Okay I’ll help to reproduce and fix the issue since it matters for me too but before that I’ll appreciate if you could help me for a quick fix since our users are suffering from the issue.
Is it safe to force Chrome67 handler (PlanB) in production until the issue is fixed? Is there any incompatibility concerns? How about users with chrome < 67?
Sorry, too many questions. Read the code, check the handlers, compare them, check the limitations in older handlers, etc. I’m not being paid for giving that much free consultancy.
Thanks, I’ll test the new version and let you know if the problem persists.
Regarding the payment, I still don’t earn much from our small project but I will pay as soon as I can, sorry. Although I think reporting issues is one of the ways that help open source projects to grow.
Yes, sure. You have helped us finding an important issue and have contributed helping others, so I was not looking at you in my other post 
It’s just that we run out of time lately and cannot resolve so many questions. Some of them require that people inspect the code in certain cases (such as in order to know the limitations of using an older Chrome handler).
Anyway, try 3.5.2 in server and client, please. And ensure clients are using 3.5.2. Note that mediasoup-client exports a version property via API.