Open ihcaesar opened 4 years ago
@ihcaesar Thanks for reporting this. Can you provide a reproducible code or a more specific manual test-case for this ?
If reproducible, there is a good chance that we can fix this in our upcoming 3.0 release.
@extmchristensen: Here's a jsFiddle to reproduce: https://jsfiddle.net/9tvL8efx/
@ihcaesar Great - I will include this test in our tests for the 3.0 release (expected early next year).
@ihcaesar - Thanks again for a nice bug reproduction test. Unfortunately, I have only got it to reproduce the bug (the alert showing) exactly once. All the other times, it either works or all state changes fails for some unknown reason. So it is difficult to isolate this bug at this time with the current jsFiddle.
However, as a part of the 3.0 release we plan to update the underlying C-SDK to a much newer version with many bugfixes, so there is a chance that this problem will be solved by that act alone.
@extmchristensen I'm still able to reproduce - however, most of the time it seems to need more runs than 10 in the for-loop:
@ihcaesar Even if I change to for-loop to 100 or 500 runs, I was not able to reproduce it more than exaxctly once.
A fast sequence of hold/resume/hold/resume/... causes the device to report an unexpected endcall event.
I've implemented resume/hold as described in: https://github.com/gnaudio/jabra-browser-integration/blob/master/docs/hold-resume-from-device.png
This log file contains the problem - this event is unexpected: 2019-11-28 14:27:21.895 INFO [39220] [HeadsetIntegrationService::Event@750] Event: endcall
JabraChromehost.log
The log file contains hold/resume operations initiated from our application, so there are no flash events. But the problem can be reproduced by responding to the flash events too.
(Jabra SPEAK 410 USB does not have this problem)