Why does Retell map declined calls to dial_no_answer

Support Help
1

Hey there,

I am facing an issue with call status mapping while making outbound calls using Retell.

Issue Description:
When an outbound call is placed:

  • If the call keeps ringing and the contact does not answer, it correctly goes to dial_no_answer.

  • However, when the contact actively declines or cuts the call, the call still goes to dial_no_answer instead of dial_busy.

Ideally, I would expect:

  • Ringing with no pickup → dial_no_answer

  • Call declined / rejected → dial_busy

Currently, both scenarios are being logged as dial_no_answer, which makes it difficult to differentiate user intent and apply accurate follow-up logic in workflows.

Any clarification or recommended best practice from your side would be highly appreciated.

2

Based on the official Retell AI documentation, the behavior you’re experiencing aligns with how the platform categorizes disconnection reasons for outbound calls that don’t connect(1).

According to the disconnection reason definitions:

  • dial_no_answer indicates “Outbound call not connected, the number dialed did not answer”(1)
  • dial_busy indicates “Outbound call not connected, the number dialed is busy”(1)
  • user_declined indicates “Outbound call not connected, user declined the call”(2)(1)

The key distinction is that dial_busy specifically refers to when the number itself is busy (typically a busy signal from the carrier), while user_declined is the status for when a user actively declines or rejects the call(2)(1).

What you should expect:

  • Ringing with no pickup → dial_no_answer(1)
  • Call declined/rejected by user → user_declined(2)(1)
  • Line busy (busy signal) → dial_busy(1)

If you’re seeing dial_no_answer for both scenarios (no pickup and active decline), this could indicate that the telephony layer isn’t properly distinguishing between these states. The underlying SIP response codes from your telephony provider determine which disconnection reason is assigned(2).

Recommended next steps:

  1. Check your call logs in the Retell Dashboard to verify the exact disconnection_reason field values(1)
  2. If using custom telephony (like Twilio or Telnyx), review the SIP response codes in your provider’s call logs to see what signals are being sent(2)
  3. Ensure your telephony provider configuration is correctly passing call rejection signals

The disconnection_reason field is available in the call object returned by the API and through webhook events(3)(4)(5).