Never-ending calls

[ertucaglar]

Which package/packages do you use?

• @stream-io/video-react-sdk
• @stream-io/video-react-native-sdk
• @stream-io/video-client

Describe the bug
If a connection problem occurs during a call that has been started somehow and the user kills their application, the call continues on Stream.io side.

Our main problem is that when a user is in a 1-1 call and another user calls someone who is in the call, we made an improvement to play a busy tone, which Stream.io normally cannot handle as far as we know.

After making this improvement, we realized that if some users kill their applications directly or have a connection problem and kill the application, the call continues on Stream.io side.

Since the call continues, when the user opens their application again and another user calls, it appears busy even though there is no active call.

Using APIs, we see that there are calls that remain open with the queryCall method.

We have two topics, does Stream manage the other party that the user is busy if a second call comes in 1-1 calls or what logical way do you suggest to manage this on your side.

If there is no such method, how can we end inactive calls.

To Reproduce
Steps to reproduce the behavior:

1. Start 1-1 call
2. Block internet connection or kill the app
3. Query calls
4. See active calls

Expected behavior
In case the application is somehow killed or cannot be reconnected, the call also needs to end on the Stream.io side.

Our other expectation is that if there is an active call in 1-1 calls, the person who initiated the second call will play a busy tone.

Screenshots

Version

• SDK version

Env:

Fill out what's applicable

React / JS client

• Browser [e.g. chrome, safari]

React Native / Expo

• OS: [iOS]
• Device or emulator [iOS Simulator, Real iOS Device]

Node JS client

• Node version: 23.11.0

Additional context
Add any other context about the problem here.

System:
  OS: macOS 15.5
  CPU: (14) arm64 Apple M3 Max
  Memory: 381.53 MB / 36.00 GB
  Shell:
    version: "5.9"
    path: /bin/zsh
Binaries:
  Node:
    version: 23.11.0
    path: /opt/homebrew/bin/node
  Yarn:
    version: 4.5.0
    path: /usr/local/bin/yarn
  npm:
    version: 10.9.2
    path: /opt/homebrew/bin/npm
  Watchman:
    version: 2025.04.14.00
    path: /opt/homebrew/bin/watchman
Managers:
  CocoaPods:
    version: 1.16.2
    path: /opt/homebrew/lib/ruby/gems/3.4.0/bin/pod
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 24.5
      - iOS 18.5
      - macOS 15.5
      - tvOS 18.5
      - visionOS 2.5
      - watchOS 11.5
  Android SDK:
    API Levels:
      - "35"
    Build Tools:
      - 35.0.0
    Android NDK: Not Found
IDEs:
  Android Studio: 2024.3 AI-243.26053.27.2432.13536105
  Xcode:
    version: 16.4/16F6
    path: /usr/bin/xcodebuild
Languages:
  Java:
    version: 17.0.15
    path: /usr/bin/javac
  Ruby:
    version: 3.4.3
    path: /opt/homebrew/opt/ruby/bin/ruby
npmPackages:
  "@react-native-community/cli": Not Found
  react:
    installed: 18.3.1
    wanted: 18.3.1
  react-native:
    installed: 0.75.4
    wanted: 0.75.4
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: true
  newArchEnabled: false
iOS:
  hermesEnabled: true
  newArchEnabled: false

[santhoshvai]

We expect the call to end when there is no active participant. When application is killed, our server will detect it after a few seconds that websocket has died. So there will be no active participant.

Can you share the code, how you are checking for active calls please

[ertucaglar]

Hello, I would like to share with you about the code side, to make your job easier, but I need to work on it a little, I will present it to you at the first opportunity.

However, in order to help you, this issue generally occurs when the following situations occur.

1- When an unexpected connection problem occurs, the user directly kills the application
2- If the user is completely in lock-screen mode in 1-1 calls and performs answer call or reject call operations using native call controls, this situation can occur

For now, we can create these two situations, as I said, I will try to do a more detailed study @santhoshvai

One of the cases is as in the ticket below.
#1832