Hi

Thanks for reaching out, Vineeth. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

How do I track latency for realtime llm models?

Thanks — I’ll help you track latency for realtime LLM models. Regarding tracking latency: realtime models emit RealtimeModelMetrics (not the regular LLMMetrics). These metrics include Time To First Audio Token (TTFT), duration, token counts, tokens/sec, and per-modality breakdowns (audio/text/cached). A TTFT value of -1 means no audio tokens were generated. How to capture and use them: • Listen for the agents framework

metrics_collected

event during a session and check for

RealtimeModelMetrics

. • Read TTFT for time-to-first-audio-token, and use duration/TTFB/TTFT plus tokens/sec to measure other latency components. • Aggregate metrics per response to compute averages, percentiles, or alert thresholds. Options for viewing and troubleshooting: • Use the Agent Observability dashboard (LiveKit Cloud) for latency breakdowns and synchronized audio playback to inspect exact timings. • Log and render metrics server-side (example patterns exist using formatted tables or dashboards) to analyze trends and correlate with traffic or model choice. If you want, tell me: • Which SDK/language you’re using (e.g., Python Agents SDK v1.3+), and • Whether you’d like a code example to listen for

metrics_collected

and extract TTFT and duration. Sources: Build Your First AI Voice Agent in Python: Complete Tutorial | LiveKit | How can I reduce latency in voice agents using STT, TTS and LLM?, with interactive elements

is eou emitted for realtime model

Short answer: yes. Regarding EOU for realtime models: realtime models emit an end‑of‑utterance signal. In LiveKit this appears as the

input_speech_stopped

event, which the Agents framework (e.g.,

RealtimeSession

) uses for turn detection when

realtime_llm

is used. Sources: How does end-of-utterance detection work in conversations?, with interactive elements

In livekit sip attributes, sip.callStatus what are the possible values for this/

Thanks — you're asking which values

sip.callStatus

can have. I don't have the enum documented here, so I need one quick detail to proceed: • Where are you seeing

sip.callStatus

? (e.g., participant attributes in LiveKit Cloud, a webhook payload, SDK logs, or an API response) If you can paste a redacted sample payload or tell me Cloud vs self-hosted and the server/SDK version, I can either interpret the value you're seeing or provide the full list of possible statuses. , with interactive elements

Current call status for the SIP call associated with this participant. Valid values are: • `active`: Participant is connected and the call is active. • • `automation`: For outbound calls using Dual-Tone Multi-Frequency (DTMF), this status indicates the callhas successfully connected, but is still dialing DTMF numbers. After all the numbers are dialed,the status changes to`active`. • • `dialing`: Call is dialing and waiting to be picked up. • • `hangup`: Call has been ended by a participant. Seedisconnect reasonsfor the specific reason. • • `ringing`: Inbound call is ringing for the caller. Status changes to`active`when the SIP participant subscribes to any remote audio tracks. • how does livekit track this? if let's say plivo is the telephony provider, how does livekit know if the call is actually dailing or active? when I do create sip participant and it succeeds but plivo fails due to number not reachable etc, what happens

Thanks — I’ll explain how LiveKit tracks

sip.callStatus

, how those states map to SIP signaling, and what happens when an external provider (like Plivo) fails to complete the call. How LiveKit tracks

sip.callStatus

• LiveKit observes SIP signaling and provider events for the outbound/inbound call and updates

sip.callStatus

based on those signals. • Typical mappings: ◦ `dialing`: outbound INVITE sent / waiting for answer. ◦ `ringing`: 180/183 responses or remote endpoint ringing for inbound calls. ◦ `active`: call confirmed (e.g., 200 OK + ACK or the SIP participant subscribes to remote audio tracks). ◦ `automation`: used when DTMF dialing is in progress after the call connects; status moves to

active

when DTMF dialing completes and the call is fully established. ◦ `hangup`: call ended; LiveKit uses disconnect reasons to indicate why. How LiveKit knows the call state with a provider like Plivo • LiveKit relies on the SIP/provider signaling and events coming from the telephony provider to determine state transitions. When Plivo (or another provider) returns SIP responses or callbacks indicating ringing, answered, or failed outcomes, LiveKit updates the participant

sip.callStatus

accordingly. • The Agents/framework detects the participant subscribing to remote audio tracks as part of determining

active

. What happens if you create a SIP participant but the provider call fails (e.g., number not reachable) • Creating a SIP participant can succeed locally in LiveKit while the outbound provider call still fails asynchronously. • If the provider reports failures (no route, number unreachable, busy, timeout, etc.), LiveKit will update

sip.callStatus

to

hangup

and include the appropriate disconnect reason. The participant will reflect that the call ended even though creation initially succeeded. If you want, tell me: • A sample webhook or participant attribute payload you’re seeing (redact sensitive data), or • Which provider and failure case you want to test (e.g., unreachable number, busy, no route), and I’ll help map the exact SIP responses/Plivo callbacks to the

sip.callStatus

and disconnect reason you should expect. , with interactive elements

Is dailing set by default or on plivo signaling

Good question — "dialing" is not a fixed default. LiveKit sets

sip.callStatus

based on SIP signaling and provider events. • LiveKit marks a participant as

dialing

when an outbound INVITE is sent and the call is awaiting answer (provisional/early session). • Subsequent provider signals update the status: ◦ Provisional responses (180/183) or ringing →

ringing

(for inbound ringing semantics). ◦ 200 OK + ACK or the participant subscribing to remote audio →

active

. ◦ Provider errors (no route, unreachable, busy, timeout, etc.) →

hangup

with a disconnect reason. • If you create the SIP participant successfully but the provider (Plivo) later fails to complete the call, LiveKit will transition from

dialing

to

hangup

when the failure is reported and include the appropriate disconnect reason. If you want, I can show an example SIP/provider event flow (INVITE → 180/183 → 200/ACK → hangup) or map specific Plivo callbacks/errors to the

sip.callStatus

and disconnect reasons. Which specific failure case should I map? , with interactive elements