Thanks — I’m responding to your question about how to see which calls were rejected or that ring forever, and best practices to monitor those outcomes. Summary — what to track • Use participant lifecycle events (webhooks) like

participant_joined

and

participant_left

and read the

disconnected_reason

on left events (e.g.,

USER_REJECTED

,

CONNECTION_TIMEOUT

,

CLIENT_INITIATED

) to classify rejections and failures. • Detect “ring forever” / unanswered calls by combining join-timeouts and silence/interaction monitoring (no join or no audio/activity within a threshold). Practical best practices to implement 1. Enable webhooks and record these events ◦ Subscribe to

participant_joined

,

participant_left

,

room_started

,

room_finished

,

ingress_started

,

ingress_ended

. ◦ Persist event ID, timestamps, participant id, and

disconnected_reason

so you can audit outcomes and deduplicate events. 1. Classify call outcomes ◦ Rejected:

participant_left

with

USER_REJECTED

or similar explicit reason. ◦ Failed/Timed out:

CONNECTION_TIMEOUT

or no

participant_joined

within setup timeout. ◦ Unanswered/ringing-forever: no agent/client join and no activity within configured ring timeout. 1. Implement timeouts & silence detection ◦ Set a sensible setup/ring timeout (e.g., N seconds). If no

participant_joined

by then, mark as unanswered. ◦ Run a short silence/activity detector after join (e.g., track last audio or interaction). If silence exceeds threshold, treat as voicemail/abandoned and close/flag the call. 1. Use fast, reliable webhook handling ◦ Acknowledge webhooks quickly (return 2xx) and process asynchronously to avoid missed or retried events. ◦ Store events durably so you can reconstruct call flows for later analysis. 1. Correlate logs and agent telemetry ◦ Combine webhook events with server logs, SIP lifecycle events, and any agent observability/traces to diagnose why calls were rejected or never connected. ◦ Keep timestamps and unique IDs to correlate across systems. 1. For outbound flows, wait-for-join pattern ◦ For controlled outbound calls, wait for the remote participant to actually join (or hit your join timeout) before marking the call as delivered; otherwise mark as undelivered/rejected. If you want, I can: • Suggest specific timeout values and an event schema for storing call outcomes. • Provide a sample webhook-processing flow or example code for silence detection. Which would you like next? Sources: Server-side | livekit/livekit_composite | DeepWiki | How to detect and handle silence during calls | Best practices for managing webhook event streams | LiveKit | Job lifecycle | LiveKit Documentation | Streamline troubleshooting with Agent Observability | LiveKit, with interactive elements

yes those fields

Thanks — I’m responding to your request for how to build more complex filters in Telephony → Call Logs. Step-by-step: create a multi-criteria filter 1. Open Telephony → Call Logs and set the Time range in the top-right. 2. Use the global search bar to add free-text matches (e.g., CallSid or participant id). 3. Use the column filter dropdowns for structured fields: ◦ Click the header for a column (e.g.,

trunk

,

dispatch_rule

,

disconnected_reason

,

duration

) and choose the filter operator (equals, contains, , ). 1. Combine multiple column filters — the dashboard applies them with AND logic so results match all criteria. 2. To filter by short duration: open the

duration

column filter and set

< 5

(seconds). 3. To show rejected calls: open

disconnected_reason

and select

USER_REJECTED

(or type it into the filter). 4. To scope to a trunk or dispatch rule: filter

trunk = your_trunk_name

and/or

dispatch_rule = your_rule

. Save and reuse • After composing filters, click Save (or Save view/preset) to persist the filter set for quick reuse. • Use Export (CSV) on the filtered result set if you want offline analysis. Example filter (rejected, short calls on trunk X) • Time range: Last 7 days •

trunk = trunk-X

•

disconnected_reason = USER_REJECTED

•

duration < 5

• (Optional) global search:

participant_id:agent-123

or

callSid:CAxxxx

If you don’t see specific columns (e.g.,

disconnected_reason

), enable them from the column selector (gear or Columns menu) in the Call Logs view. Would you like a screenshot-style walkthrough for each click, or the exact field names to use for creating a saved preset? Which do you prefer? , with interactive elements