Can you help me with this edge case? Most of the participant could play audio, but a few couldn't.


We recently had a call with 20 people, where most of them could play audio, but few couldn't.

We interviewed one of the participants and here are the information I got from the user and the session log.

  • User used Windows 11. We tested both on Microsoft Edge and Chrome for the call, verified the browser and PC setting that the our website has a permission to access the video and microphone. We had other participants' using windows and edge, so we do not know why this particular user has an issue.
  • the user's console and the session log shows "error setting up server-side producer: PermissionsError: not permitted to send audio track cam-audio".

*note that we encountered iOS and safari requires the participants to tap the screen to play different sounds. We found that turning the mic on and sending audio track (though the we don't receive it on sfu) automatically lets the user's browser play any audio. This error is likely to come from this implementation and we also see it on the log of the successful session.

Here is the session ID

c1a54fd5-b4f5-49d8-9155-b07f0bbd4e32 (for Edge)

1dd8cdbd-a8aa-4c89-926f-2260555b952a(for Chrome)

7427cb69-feeb-4ed5-be07-5b2a8ac51474 (for Chrome on iPad and this session could play audio)

The users are pretty frustrated with this issue, so a reply is super helpful for us.




  • mark_at_daily
    mark_at_daily Community Manager, Dailynista admin


    This error ("error setting up server-side producer: PermissionsError: not permitted to send audio track cam-audio") means that the user did not have permission to send audio. In checking the logs, I see that you are setting permissions for users to not send audio (e.g. "permissions":{"hp":true,"cs":"v"}), where cs is canSend and v is video.

    As you pointed out, autoplay rules, especially on iOS are strict. They generally require a user gesture to result in audio playing (which includes accepting audio permissions). My hunch is that since users are joining without audio, the browser's autoplay rules are preventing audio from playing.

    You should be able to catch autoplay errors when trying to play() the audio element (assuming an audio track is attached to the DOM element).

    Hope this helps or at least gives you a clue!