### Answer When handling transfer failures in custom LLM implementations, you can monitor the call status through the disconnection_reason field available in the call object. [(1) ]() The disconnection_reason provides specific error codes for transfer-related failures, including: - **transfer_cancelled**: When a transfer is cancelled - **transfer_bridged**: When the call was successfully transferred You can access this information through: 1. **Webhooks**: Subscribe to the

call_ended

or

call_analyzed

webhook events to receive the disconnection_reason when the call ends 2. **Get Call API**: Retrieve the call object after the call ends to check the disconnection_reason field [(2) ]() [(1) ]() The LLM WebSocket itself doesn't send a real-time event specifically for transfer failures during the call. However, you can track the call status through webhooks to handle post-transfer scenarios. [(1) ]() [(3) ]() To initiate a transfer in custom LLM, send a response event with the

transfer_number

field set: [(4) ]()

json
{
  "response_type": "response",
  "response_id": 1,
  "content": "Transferring you now",
  "content_complete": true,
  "transfer_number": "+1234567890"
}

​ To learn more, see the sources I considered: [[1] Register Phone Call](https://docs.retellai.com/api-references/register-phone-call) [[2] List Calls](https://docs.retellai.com/api-references/list-calls) [[3] Webhook](https://www.retellai.com/glossary/webhook) [[4] LLM WebSocket](https://docs.retellai.com/api-references/llm-websocket) ​

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.

### Answer When a transfer fails due to the number being unavailable, not picked up, or other issues, Retell provides specific disconnection_reason values to help you identify what went wrong [(1) ]() : Common transfer failure reasons include: - **Could not detect human**: If human detection is enabled, the call may fail if a human is not successfully detected . This can happen when: - No human was actually present (e.g., it was an IVR or voicemail) - The other party spoke, but only after the detection timeout expired - The speech was too similar to an IVR or voicemail and was not recognized as human - **Telephony issues**: Call transfer failures occur for similar reasons as outbound call failures . The SIP connection log is available in the call logs and is useful for diagnosing the failure reason How to handle these cases: 1. **Monitor webhook events**: Subscribe to transfer-specific webhook events [(2) ]() : - `transfer_started`: Triggered when a transfer is initiated - `transfer_bridged`: Triggered when a transfer successfully bridges - `transfer_cancelled`: Triggered when a transfer is cancelled or fails to connect - `transfer_ended`: Triggered when the transfer leg ends 2. **Check the call object**: All transfer webhook events include

transfer_destination

and

transfer_option

(if available) , along with the full call data to help you understand what happened 3. **Review SIP logs**: For telephony-related failures, examine the SIP connection log available in the call logs to diagnose the specific failure reason [(1) ]()

​ To learn more, see the sources I considered: [[1] Debug call transfer failure](https://docs.retellai.com/reliability/call-performance) [[2] Webhook Overview](https://docs.retellai.com/features/webhook-overview) ​

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.