### Answer The information sources don't cover this specific scenario (joining an already-in-progress call with a 10-13s delay before first speech) , so I can't give a definitive root cause. A few relevant things I can point to:

begin_message_delay_ms

is a configurable setting that delays the agent's first message — valid range is [0, 5000] ms, and it's only applicable when the agent speaks first [(1) ]() [(2) ]() . If this is set high, or if your integration logic has its own added delay before connecting the agent to the live call, that could compound with any pipeline latency. For diagnosing the actual delay, you can pull the

latency

object from the Get Call API, which breaks down

asr

,

llm

,

tts

, and

e2e

timing per call, including `p50`/`p90`/`max` values [(3) ]() . That would let you see whether the delay is coming from LLM/TTS/ASR specifically or something else (e.g., telephony/call-joining overhead) , since e2e latency doesn't include network trip time to the user's frontend . Separately, production voice infrastructure in general is noted to be sensitive to real-time response windows, and delays of even a few seconds can cause callers to assume the system failed or dropped [(4) ]() . There's also a Discord thread where a similar high end-to-end latency issue (phone vs. web calls) was investigated — in that case, part of the delay was attributed to turn-taking behavior and pauses being counted toward E2E latency, and the team asked for call IDs to review directly [(5) ]() . Given your case involves joining an

already-in-progress call specifically, I'd recommend sharing the call ID with the team via their support forum, since that thread shows this is how they typically debug latency outliers . If you want, share a call ID and I can help you interpret the latency breakdown fields once you pull them via the Get Call API [(3) ]() .

​ To learn more, see the sources I considered: [[1] Create Voice Agent](https://docs.retellai.com/api-references/create-agent) [[2] Get Voice Agent](https://docs.retellai.com/api-references/get-agent) [[3] Check actual latency](https://docs.retellai.com/reliability/check-actual-latency) [[4] What It Takes to Build and Scale AI Voice Agents Effectively Without Them Breaking | Retell AI](https://www.retellai.com/blog/what-it-takes-to-build-and-scale-ai-voice-agents-effectively-without-them-breaking) [[5] High end to end latency in phone calls](https://discord.com/channels/1186424376300679209/1450956304288845855) ​

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

@AI Evy For an agent SIP-bridged into a live in-progress call, what turn-taking config do you recommend? Can empty begin_message + interruption_sensitivity 0.8 make it defer indefinitely while a human talks continuously? Does stt_mode accurate vs fast materially change time-to-first-word? What does model_high_priority actually change, and would it help here? What is a normal time-to-first-word for this setup? Is 10-13s a misconfiguration or a platform-side issue?

### Answer I don't have specific documentation on turn-taking configuration for SIP-bridged agents joining an already-in-progress call, so I can't give definitive recommendations for that exact scenario. Here's what the sources do support on your specific questions: **Turn-taking/interruption_sensitivity behavior**: The sources don't document

interruption_sensitivity

or

begin_message

behavior in enough detail to confirm whether a combination of empty begin_message + interruption_sensitivity 0.8 would cause indefinite deferral while a human talks continuously. I can't answer this without speculating. **stt_mode (accurate vs. fast) and time-to-first-word**: The accuracy-optimized transcription mode intentionally waits longer than the speed-optimized mode, incurring about 200ms more latency, because it waits for more context before finalizing a transcript [(1) ]() , [(2) ]() . So yes, it materially adds latency — the speed-optimized mode is recommended when responsiveness matters more than transcript precision . However, this ~200ms difference is much smaller than the 10-13s delay you're describing, so it's unlikely to be the primary driver of your issue. **model_high_priority**: The sources don't document a setting called

model_high_priority

. What is documented is "fast tier," which routes LLM calls through dedicated, high-priority infrastructure, reducing both average response time and call-to-call variance, at a higher cost than the standard model rate . If

model_high_priority

refers to this fast tier feature, it could help tighten inconsistent response times, but I can't confirm the exact parameter name or behavior without it being explicitly documented. **Normal time-to-first-word / is 10-13s a misconfiguration**: The sources state that delays b

eyond roughly 1.5s of estimated latency are worth addressing, and that turtle-icon marked features which add latency should be minimized to keep estimated latency under 1.5s . A related Discord thread investigating a similar high end-to-end latency case found that in some instances, part of the delay was due to turn-taking logic waiting for a "pause" before the agent spoke, and that pause time is counted toward end-to-end latency [(3) ]() . In that thread, the team also noted median LLM latency around 3600ms+ was flagged as a likely contributor on a custom LLM setup . Given your median is 10-13s (max 27s) , this is far outside normal ranges described in the sources (sub-2.5s p50 is treated as the threshold for "high latency" needing fixes) [(4) ]() , so this points to a misconfiguration or an underlying pipeline/network issue rather than expected behavior — but the sources don't cover the specific SIP-bridge-into-live-call scenario to confirm root cause. I'd recommend pulling the

latency

breakdown via the Get Call API (fields:

e2e

,

asr

,

llm

,

tts

,

knowledge_base

) for one of these slow calls to see where the 10-13s is actually being spent [(5) ]() , and sharing that call ID with support for a deeper look, similar to how the team investigated the Discord case [(3) ]() .

​ To learn more, see the sources I considered: [[1] Balance between transcription accuracy and latency](https://docs.retellai.com/build/transcription-mode) [[2] Troubleshoot high latency](https://docs.retellai.com/reliability/troubleshoot-latency) [[3] High end to end latency in phone calls](https://discord.com/channels/1186424376300679209/1450956304288845855) [[4] Address metric issues](https://docs.retellai.com/ai-qa/address-metric-issues) [[5] Check actual latency](https://docs.retellai.com/reliability/check-actual-latency) ​

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

all) [(2) ]() [(3) ]() . The sources don't describe detection timing, interaction with

end_call_after_silence_ms

, or why a call might run the full duration instead of hanging up on IVR detection. **model_high_priority**: Not present in any of the available sources — I can't confirm what it changes or its effect on

llm_p50

. None of your five questions can be answered from these three schema references. This requires deeper product/behavior documentation not included here. I'd recommend sharing these specific questions along with a call ID through the support channel referenced in the earlier thread, since the team can inspect actual call behavior directly.

### Answer The available sources ( [(1) ]() , [(2) ]() , [(3) ]() ) only document the request/response schemas for Register Phone Call, Create Voice Agent, and Create Phone Call — they don't contain guidance on turn-taking behavior, end-of-turn detection, IVR interaction with begin gates, or

model_high_priority

. I can only confirm what fields exist in these schemas, not their runtime behavior for your specific scenario. What I can confirm from these sources: **begin_after_user_silence_ms**: This is a documented field under

retell_llm

and

conversation_flow

configs, with an example value of

2000

shown in the schema [(1) ]() [(2) ]() [(3) ]() . The sources don't state what happens if it's left unset, so I can't confirm whether an unset value causes indefinite waiting or what value to recommend for a SIP-bridged, already-in-progress call scenario. **begin_message**: Documented as a field under

retell_llm

, with example

"Hey I am a virtual assistant calling from Retell Hospital."

. No guidance is given on behavior when set to an empty string combined with

start_speaker: "user"

. **start_speaker**: Documented under

conversation_flow

with example value

"agent"

[(1) ]() [(3) ]() . The sources don't discuss

"user"

as a value or its interaction with silence timers. **ivr_option**: Documented with an example action of

{"type": "hangup"}

[(1) ](

​ To learn more, see the sources I considered: [[1] Register Phone Call](https://docs.retellai.com/api-references/register-phone-call) [[2] Create Voice Agent](https://docs.retellai.com/api-references/create-agent) [[3] Create Phone Call](https://docs.retellai.com/api-references/create-phone-call) ​

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