PSTN Dial-Out Incorrectly Reports Call as Accepted When User Rejects Call or Call Goes to Voicemail

We have integrated the Zoom Video SDK into our platform and are using the PSTN dial-out feature to connect participants via phone calls. However, we are experiencing a critical issue with call state detection that affects the user experience and our application logic.

Problem Description: When initiating outbound calls using the PSTN dial-out functionality, the SDK consistently reports calls as “accepted” or “connected” even when the recipient explicitly rejects the call or when the call is forwarded to voicemail. This behavior occurs regardless of whether the voicemail system picks up or not.

Expected Behavior: The SDK should accurately distinguish between:

  • Call accepted by the actual recipient
  • Call rejected by the recipient
  • Call not answered (timeout)

Actual Behavior: All call scenarios mentioned above are being reported as successful connections, making it impossible for our application to handle rejected calls appropriately or provide accurate feedback to users.

Testing Details:

  • Tested with both Brazilian (BR) and United States (US) phone numbers
  • Issue occurs consistently across different carriers and phone types
  • Both mobile and landline numbers exhibit the same behavior
  • Problem persists whether voicemail is enabled or disabled on the recipient’s phone

Impact: This issue prevents our application from:

  • Properly tracking call success rates
  • Implementing retry logic for failed calls
  • Providing accurate user feedback about call status
  • Managing billing and usage analytics correctly

Environment:

  • Platform: Web
  • SDK Version: 2.1.5
  • Browser: Chrome 137.0.7151.104 (Official Build) (arm64)
  • Operating System: MacOS 15.4.1 (24E263)

Steps to Reproduce:

  1. Initialize Zoom Video SDK with PSTN dial-out capability
  2. Initiate an outbound call to a phone number
  3. Have the recipient reject the call or let it go to voicemail
  4. Observe the call status reported by the SDK

Additional Information: We are using the standard PSTN dial-out implementation as documented in the official Zoom Video SDK documentation. The issue appears to be related to how the SDK interprets carrier-level call signaling rather than our implementation.

Has anyone else experienced similar issues with PSTN call state detection? Any workarounds or solutions would be greatly appreciated.

Hey @samuelhgf

Thanks for your feedback.

May I confirm if you’re relying on the dialout-state-change event and interpreting code 8 as a successful connection?

If possible, could you kindly share a few session IDs where the issue was observed? This would greatly help us with further troubleshooting.

Thanks
Vic

Hey @vic.yang

We were logging all states from dialout-state-change and didn’t show up a status 8.

This is the session IDs:

9f23adc0-a7d7-4390-9d3b-797303643a51

4Zk8dBNBTH+U7v7zUvELjA==

Thanks,

Samuel França

Hi @samuelhgf

4Zk8dBNBTH+U7v7zUvELjA==

After analyzing the logs, the dialout-state-change event returned code: 4, which indicates DialoutState.Busy, meaning the phone line was busy and the call could not be connected

Thanks
Vic

Hi @vic.yang

Thanks for that. I will try to reproduce again and let you know

Thanks!

Samuel França