Thanks — I hear you: when you pick up as the supervisor during a warm transfer the agent audio can be delayed 10–20s, and you want debugging steps and ways to speed that up on LiveKit Cloud (Ship plan). Below are focused checks, quick fixes, and diagnostic steps to help narrow the bottleneck. Quick checklist (try these first) • Verify network proximity: Confirm the supervisor’s client and the agent are using LiveKit regional endpoints closest to them. Connecting to a nearby LiveKit region reduces setup time. • Use provider-specific/optimized endpoints: If your SIP trunk provider offers a lower-latency or dedicated endpoint, use it for transfers. • Enable Instant Connect / pre-warm policies: Pre-establish the agent’s media path (pre-warm connections) before the supervisor pickup when your flow allows it. • Confirm SIP trunk performance: Ensure your SIP provider supports fast connection setup; slow INVITE/200 OK exchange from the provider can add many seconds. What to measure (important metrics to collect) • Time to First Tone/Time to First Packet (TTFT/TTFB): Measure how long from supervisor pick-up to the first media packet. This isolates network/setup vs media path problems. • SIP signaling timing: Capture timestamps for INVITE, 200 OK, ACK between LiveKit and your SIP provider during the transfer. • LiveKit logs/events around the transfer: Note any errors, reconnects, or codec renegotiation events at the time of pickup. Targeted debugging steps 1. Capture signaling and media timelines ◦ Gather SIP traces (INVITE/200/ACK) from your SIP provider and call controller timestamps for when the supervisor answers. ◦ Collect LiveKit server/SDK logs for the transfer event (timestamps for transfer start, supervisor join, track subscription). 1. Confirm media negotiation isn’t blocking ◦ Check for codec renegotiation or re-INVITEs during pickup. Re-negotiation can add seconds. ◦ Ensure both sides support a common codec and avoid full SDP renegotiation if possible. 1. Test pre-warming/persistent connections ◦ Simulate a warm transfer but keep the agent’s connection active and subscribed so media path is already established when supervisor picks up. If delay disappears, the problem is connection establishment time. 1. Reproduce with simplified flow ◦ Run a minimal test that transfers between two endpoints under controlled network conditions to determine if delay is systemic or specific to your production SIP provider or client setup. 1. Look for audio capture/source problems ◦ If the agent’s microphone or audio source is being (re)initialized when the supervisor picks up, that can cause delays. Confirm agent audiocapture is ready earlier in the flow. Optimizations known to reduce delay • Pre-warm agent connection or keep agent media active prior to supervisor pickup. • Use streaming/low-latency providers for STT/TTS or other AI services if those are involved in the transfer flow. • Deploy agents or route media through regions closest to your SIP provider and supervisor endpoints. • Use dedicated/priority or provider-specific SIP endpoints if available to reduce provider-side setup time. • Avoid unnecessary SDP renegotiation during transfer; prefer track subscription reuse where possible. If you can, please share (or confirm): • Whether you observe the delay before or after the SIP 200 OK to the transfer INVITE (i.e., is signaling slow or media delivery slow). • A short timeline of events with timestamps from your logs (transfer start, supervisor answer, first agent audio). • Which SIP trunk/provider you use and whether you’ve seen similar delays on other flows. I can help interpret traces/timestamps you paste here and suggest concrete changes based on whether the delay is signaling, codec negotiation, media path setup, or audio capture. Sources: How can I reduce latency in voice agents using STT, TTS and LLM? | LiveKit | Preserving Caller ID During SIP Transfers in LiveKit Agents | Resolving "InvalidState - failed to capture frame" errors in AudioSource | How to match the latency of the homepage agent | LiveKit