-
Notifications
You must be signed in to change notification settings - Fork 13k
fix: Incoming VoIP calls playing "dial" sound when answered #36225
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Looks like this PR is ready to merge! 🎉 |
|
093e887 to
931058e
Compare
🦋 Changeset detectedLatest commit: 1eff686 The changes in this PR will be included in the next version bump. This PR includes changesets to release 37 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## develop #36225 +/- ##
========================================
Coverage 64.54% 64.54%
========================================
Files 3148 3148
Lines 104632 104632
Branches 19775 19820 +45
========================================
+ Hits 67531 67533 +2
Misses 34416 34416
+ Partials 2685 2683 -2
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
Proposed changes (including videos or screenshots)
The VoIP client emits an "outgoingcall" event whenever a call is being established, but an incoming call also has that state when it's first accepted. This made the "dialing" sound be played after the call is accepted, which should not have been the case.
In order to avoid disrupting the current implementation of the VoipClient, a check in the "VoipProvider" was added to ensure that the sound is only played if it's an outgoing call. Ideally, the events that are dispatched from the VoipProvider should be abstract and not share any "VoIP" concepts with the UI, just providing information and states that are relevant for the UI to render the appropriate view.
There's a lot of places where this mix of concepts happen in the current implementation, so a choice was made to provide a simple fix and handle this edge case closer to the UI logic, avoiding breaking any data/event flow from the VoipClient class.
Issue(s)
VSTAB-27
Steps to test or reproduce
Further comments
Seems to have been introduced here: https://github.com/RocketChat/Rocket.Chat/pull/35666/files#diff-529f11d11b8544afbf254f0abacfa6bf5d748024ffa68b14353dba21be904ad6L1-L28
The play function was async at first and depended on a DOM query selector, so by inference it's being assumed that a race condition was "hiding" the issue, and the new CustomSounds "manager" just exposed the existing issue.