V3 gateway plays the agent's first utterance ~1s before the browser's media path is live

Support Help
1

On /v3/create-web-call, our callers hear the agent’s greeting from the middle instead of the first word.

Measured in the browser, relative to start_timestamp:

  • First inbound audio packet: +1250ms
  • Agent’s first word: +222ms (median of 10 calls)

The agent speaks for about a second before the browser can play anything.

We are on custom-llm, so we can see our own side too. We return the opener text before start_timestamp on most calls, and Retell still holds it until +0.2s. So the release is gated on the SDP answer, not on the media being ready.

Example call: call_3a59f78ce70d285e60cb6f252ea, first word at +0.205s. Setup: retell-sdk 6.0.1, retell-client-js-sdk 3.0.1, transport: "gateway", Chrome on macOS.

Also, is 2026-09-30 a hard removal for /v2/create-web-call, or a deprecation?

Happy to share the other calls or our browser instrumentation if that helps.

2

Hello @maxi I’m checking the Call ID with the team and will get back to you as soon as I have an update.

Thank You

3

Hey @maxi You’re reading it right. On v3 gateway, start_timestamp is stamped when the browser participant joins the gateway room (signaling done at the SFU), and the begin response is released immediately after — we don’t gate on ICE/DTLS finishing or on the first server→browser RTP being playable. Chrome’s media-path warmup after that (a few hundred ms up to ~1s) clips the opener. Expected behavior, not a regression.
The knob is the agent’s begin_message_delay_ms (0–5000ms). Given your +1250ms first-inbound-packet, set it to ~1000–1500ms and the agent will hold the first utterance for that long past start_timestamp.

On 2026-09-30: that deadline is for the legacy browser SDK retell-client-js-sdk v2.x / Create Web Call v2. You’re already on retell-client-js-sdk@3.0.1 + v3 createWebCall, so nothing to migrate on your side.

Ref: Retell legacy browser JavaScript SDK deprecated on September 30, 2026

Thank You

4

Thanks. Two questions.

  1. We rolled back to Create Web Call v2 and retell-client-js-sdk 2.x yesterday, so the
    Sept 30 removal does apply to us. Does that date remove both the legacy browser SDK
    2.x and POST /v2/create-web-call?

  2. begin_message_delay_ms is a fixed delay, but connection time varies, so a user on a
    slow network or a TURN relay will still clip. On v2 we needed no delay, because the
    LiveKit room reported the participant as connected before the begin response went
    out. Is an equivalent media ready signal on the roadmap for the gateway, such as
    first RTP or a client event?

5

Hello @maxi quick corrections and answers:

  1. Yes, 09/30/2026 removes both pieces. The legacy browser SDK retell-client-js-sdk 2.x and POST /v2/create-web-call are both deprecated on that date (notice). My earlier note said you were already off the deprecated path — that only applied to your prior v3 setup. Since you’ve rolled back to v2, you’ll need to plan a return to RetellClient + POST /v3/create-web-call before 09/30. Existing integrations keep working until then.
  2. You’re reading the gateway correctly — the begin response is released after beginMessageDelayMs measured from start_timestamp, with no first-RTP / track-subscribe / client-ready gate today, so a fixed delay can’t fully cover variable ICE/TURN warmup. This is a fair product ask, but I don’t want to commit to a specific mechanism or ETA. I’ll raise it with engineering — a per-call “media path ready” signal (e.g. first inbound RTP or a client ready event) is the right shape — and follow up here with what’s feasible. In the meantime begin_message_delay_ms (max 5000ms) tuned to your p95 is the only knob.