Description
I’m hoping theres a way to set the default join behavior of dial-out phone users to muted when joining. When a computer user calls startAudio we have the option in SDK to set the AudioOption of “mute” to true enforcing the user muted on entry of meeting. However without this option for phone users i’m running into some issues.
If a mobile web user connects via dial-out i’m forced to listen to user-updated events and manually mute that joined phone user. However this gets sketchy because if this user decides to pause the web browser by say checking a text message on their phone or opening another app – the zoom websocket connection dies and a weird behavior i’m noticing is that when they reconnect they join unmuted. Its strange.
Please let me know any guidance on this or if there is a known way to force phone users into a muted state on join.
How To Reproduce
*1. Join a meeting via mobile web
*2. Connect to audio via dial-out function
*3. Go to another app or just home on your phone for about 30 seconds so you lose websocket connection
4. Go back to web browswer where zoom call is being hosted – you’ll be unmuted even though host never unmuted you.
Can I confirm that you’re using the stream.inviteByPhone method and specifying the callMe option? This configuration will bind the PSTN audio to the calling user (the current user).
I’m hoping theres a way to set the default join behavior of dial-out phone users to muted when joining.
We currently don’t provide a mute option in the stream.inviteByPhone method similar to stream.startAudio, but you can call stream.muteAudio immediately after stream.inviteByPhone.
I am using inviteByPhone with the callMe: true. I am manually muting when they join. Is there anyway you guys could add an additional DialOutOption such as mute? In addition to callMe and pressOne? This would be particularly useful because say if the websocket connection dies during their acceptance of the call ( which is fairly likely given the time the user may take to accept and press 1) the stream.muteAudio ( by either participant or host ) wouldn’t register and you’d end up with an unmuted participant without the ability to mute them cuz they could go straight back to check their texts or w/e before they come back to the web meeting at somepoint…
Thats great to hear the team is addressing the reconnect unmuted issue
Thanks for sharing more context on this issue with us.
I assume you’re looking for a method like muteUponStartAudio, which is a session-level switch that automatically mutes users’ audio when they start audio for the first time. It’s feasible to support this in the Video SDK. Could you help submit a feature request for it?
Typically, we assess the importance and complexity of a feature, and then plan its rollout based on the current roadmap. If it’s a simple request, it could be included as early as the next release.
Please stay tuned to our release notes for updates.
They are consistenly just being unmuted for no reason – this user is connected via computer + phone ( dial out )
I have no idea why this happens on desktop users. I understood on iphone users that their websocket connection was dying say if they were texting and when they rejoined it unmuted them due to a bug… but no clue why desktop users get unmuted?
I"m hoping the feature request I put it will fix this but I’m concerned it wont… .was just hoping you could provide some insight or look into this further… This is a consistent issue on our meetings and we have to verbally announce asking phone users to mute their own device…
After analyzing the logs for this session, we found that this user joined the session via Chrome and had set audio_compatible_mode=1 in the JWT, enabling WebRTC audio mode.
However, possibly due to firewall restrictions, the connection to our server on ports 8802 or 8803 was blocked. This caused the user to experience periodic meeting failovers and reconnections. You can listen to the connection-change event to detect this situation, where a state: Reconnecting payload will be returned.
The user was using PSTN call-out for audio, and as discussed earlier, after reconnection, the PSTN audio resets to unmute, which explains the consistent unmuting issue.
We are adjusting our server port strategy and will soon allow connections over port 443, which should improve audio services under strict network policies.
If you look at this session: L7Mb2GkeQKW/mz+fvJYtyA==
This issue is still persisting even with the attempt to mute them on reconnect with i added it doesn’t fix the issue.
See participant Paul Lipinski
He must of “reconnected” about 15 times as listed in the dashboard session info. Each time he joins unmuted. If he doesn’t mute his local line it can derail our meeting. We have no control of muting this person because they are consistently being disconected and reconnected.
I love most everything from the product so far and we have big plans moving forward but these phone issues i’m running into are forcing me to consider switching platforms – and trust me I do not want to do that. Is there any hope the team will be able to resolve the phone issues i’ve identified? Even if you couldn’t resolve the reconnection issue why are they joining unmuted? I put in a feature request as you suggested but not sure its gotten any attention. Sorry for sounding so frustrated but its really hurting our product at times.
User Beth Thome has connected/reconnected like 30 times all unmuted.
Is audio_compatible_mode=1 not a reliable method of connection ? I originally used this because it solved a mac robot sound issue bug but I kept using it cuz it allowed me to enable things like backgroundNoiseSuppression. Is there problems relating to all this with using that mode?
Are you able to take a look at this? Or anyone on the team? I’m not sure @vic.yang is around and it would be super helpful to get some clarity on these issues i’m facing.
The firewall might be prevent the audiobridge from connecting, and hence failing.
We will move to port 443 and support muteUponStartAudio in the upcoming version.
We have completed the deployment of the server’s port 443. As for the next version of the Video SDK(1.12.10), it is expected to be released in late October.