Thanks — I hear you: you’re not seeing the

sip.callStatus = "active"

event and want to know why. I’ll walk through the most common causes and quick checks so we can narrow it down. Quick checklist (what to verify first) • Confirm the call was actually answered.

active

is set only after the callee answers and media is flowing. • Make sure your app is listening for

participant_attributes_changed

immediately after joining the room — that event delivers

sip.callStatus

updates. • Check whether the SIP trunk/provider is sending a proper answer (e.g., a 200 OK with SDP). If the provider never signals answer, the status may stay `dialing`/`ringing`. • Verify the participant didn’t hang up before answer. If it goes from

ringing

straight to

hangup

, you won’t see

active

. • Try a different SIP endpoint or trunk to rule out provider-specific signaling or early-media behavior. Specific debugging steps 1. Add comprehensive logging for every

participant_attributes_changed

event to confirm whether any SIP attributes arrive (e.g.,

sip.phoneNumber

,

sip.callID

) or whether no SIP attributes show up at all. 2. Confirm your event listener is registered right after joining the room. If you join after the attribute change, you can miss the

active

transition. 3. Inspect SIP/trunk call detail records or provider logs to confirm when the call was answered and whether an SDP 200 OK was exchanged. 4. If you use voice-activity-based detection in your AgentSession, confirm

vad

is configured correctly so media presence is detected. 5. Test with a controlled call you know will be answered (e.g., from a SIP softphone) to reproduce the issue with minimal variables. If helpful, tell me: • How you’re registering the

participant_attributes_changed

handler (a short code snippet or where in your join flow you attach it). • Whether you see other SIP attributes arriving at all. • Which SIP provider/trunk you’re using (or if you can test with another endpoint). • Example logs around the call lifecycle (dialing → ringing → hangup/active), if available. I can then suggest targeted changes to your listener placement, logging to capture the missing event, or tests to isolate provider vs. client behavior. Sources: SIP Lifecycle Management Agent | LiveKit Documentation | sip | livekit/livekit_composite | DeepWiki, with interactive elements