You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a conference member is put on hold, the member should be both deaf and mute. Instead, the member can hear the other participants talking. I looked at the code for conference_api_sub_hold(), it only puts the call on mute.
Member "hold" followed by member "deaf" does give the desired effect, but that is two different API calls.
Is this by design or a defect?
The text was updated successfully, but these errors were encountered:
it sets MFLAG_HOLD which should make the user not hear anything. This was backported from an internal branch where we made the feature for our own needs, if its not working its missing in a condition in conference loop somewhere. Look at the places where we check for the deaf flag that dont also check for hold flag.
Ah, I forgot all about this. Yes, I did fix it in my local copy and moved on. Since no one else confirmed the bug, it simply slipped my mind. I can create a PR and suggest my fix.
When a conference member is put on hold, the member should be both deaf and mute. Instead, the member can hear the other participants talking. I looked at the code for conference_api_sub_hold(), it only puts the call on mute.
Member "hold" followed by member "deaf" does give the desired effect, but that is two different API calls.
Is this by design or a defect?
The text was updated successfully, but these errors were encountered: