Skip to content
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

Call Decline Not Working in iOS (Background, Terminated, and Lockscreen) in Version 0.5.5 #782

Open
dhara6894 opened this issue Oct 22, 2024 · 1 comment
Assignees

Comments

@dhara6894
Copy link

In stream-video-flutter version 0.5.5, the call decline feature is not working as expected on iOS. While this functionality works correctly on Android, iOS devices do not behave as expected in the following scenarios:

When the app is in the background,
When the app is terminated (killed),
When the device is locked.

When the receiver declines the call on iOS, the caller still sees "calling" as if the call was not declined. This issue occurs only on iOS, while Android devices handle it properly.

Steps to Reproduce:

  1. Install the app on both iOS and Android devices.
  2. Make a direct call from the Android device (caller).
  3. Try to decline the call on the iOS device (receiver) in the following scenarios:
  • While the app is in the background.
  • When the app has been terminated.
  • When the device is locked.
  1. Notice that, on the iOS device, the call is not properly declined, and the caller still sees the "calling" status even though the call should have been declined.

Expected Behavior:

  • The call should be properly declined on iOS, just as it does on Android.
  • The call UI on the caller's side should reflect that the call has been declined.

Actual Behavior:

On iOS, when the receiver declines the call in background, terminated, or lockscreen modes, the caller still sees "calling," indicating the call was not declined properly.

@deven98 deven98 self-assigned this Oct 28, 2024
@deven98
Copy link
Contributor

deven98 commented Oct 28, 2024

Hi @dhara6894 👋

Thanks for the feedback !

As I mentioned on the other issue, we are currently doing a pretty big rewrite of the package with this PR: #776
After testing it out with the same branch, we could not reproduce this issue. If possible, can you test this out with the PR branch and let us know if this works?

If you do not have time, this branch should be soon merged into main and you can test it out in the next release.

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants