### Answer This is a known issue where Retell can spin up duplicate sessions if the initial audio stream handshake is delayed or misread. [(1) ]() The first session(s) may stay as "dead air" while another valid call starts almost immediately, creating multiple call records. How to identify and filter these: 1. Check the

call_status

field in the call object—failed calls often show

"error"

while successful ones show

"ended"

. 2. Look for calls with the disconnection reason related to ASR failure (e.g., "ASR closed, most likely due to no audio received") . Recommended workarounds: - **Deduplicate by timing + caller ID**: Ignore calls if multiple calls from the same number start within a few seconds. - **Filter by `call_status`**: In your webhook handler, filter out calls where

call_status

is

"error"

vs

"ended"

. - **Check duration**: Some duplicate calls may have

duration_ms

of 0 or very short durations. You can retrieve call details using the Get Call endpoint to inspect the

call_status

and

disconnection_reason

fields for each call ID. [(2) ]() Unfortunately, this behavior cannot be fully prevented client-side—it's related to how the audio stream handshake occurs on Retell's infrastructure. [(1) ]()

​ To learn more, see the sources I considered: [[1] Two Call Records Created for a Single Customer Call](https://discord.com/channels/1186424376300679209/1387830300041543801) [[2] Get Call](https://docs.retellai.com/api-references/get-call) ​

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

Here are the call ids in order:

call_65e4e51fff82b8a317c3ed52709
call_e81302193db121c4619de4a5973
call_d40b2d72639b58f8b52ed403812

They all have session status as "ended". We only see the first call being made from our side and received 3 sets of webhook events and the customer got 3 calls back to back for that one request