Thanks — I’m sorry you’re seeing the SIP participant’s audio cut out during a room composite egress. I’ll help troubleshoot this. To be efficient, I’ll first cover the most likely causes and quick checks, then ask a few targeted questions so we can narrow it down. What to check first (most common causes) • Silence-detection / agent logic: If you’re using any agent silence detection (VAD) or a

user_away_timeout

, that logic can mark the SIP user as “away” or trigger muting/disconnect after a period of silence. Review any silence detection timers or end-of-turn logic. • Track state in the room: Verify whether the SIP participant’s audio track is still published when the audio cuts out. If the track is muted or unpublished, egress (recording) will stop receiving audio. • Audio pipeline errors / buffering: Look for errors like “failed to capture frame” or audio source queue overflows which can cause gaps or cutoffs. • Egress behavior: During room composite egress, LiveKit captures published tracks. If the SIP client is silently stopping RTP or not sending media, the egress will record silence. • Default agent filtering: By default agents listen to standard participants and SIP callers. If there were changes to filters (e.g., ignoring SIP sources), that could affect audio capture. Targeted questions (these will help me point to the exact fix) 1. Are you running any custom silence-detection or agent logic that might mark the user away or mute them? If yes, what are the silence thresholds? 2. When the audio cuts out, does the SIP participant still appear in the room as “connected”? Does their audio track show as published or unpublished (or muted)? 3. Is this happening only during composite egress recordings, or do live SIP participants also hear the cutoff in real time? 4. Do you see any errors in the server logs or egress logs around the time audio stops (for example, “failed to capture frame” or VAD-related logs)? 5. How long into the call does the audio typically cut out? Is it consistent (e.g., always after 30s) or intermittent? 6. Are you using any intermediary (SIP proxy/IMS) between LiveKit and the SIP endpoint that might be sending re-INVITEs or changing media state? 7. What codecs are negotiated for the SIP leg, and is any transcoding happening on egress? Short next steps you can try right away • Temporarily disable any silence-detection /

user_away_timeout

logic and reproduce the call to see if audio stays stable. • While reproducing, watch participant track state (published/muted/unpublished) via the API or logs to see if the track disappears when audio cuts. • Check egress logs for capture/frame errors during the time of the cutoff. What I can do next • If you share the answers to the questions above (and any relevant log snippets showing timestamps around the cutoff), I’ll help interpret them and suggest precise fixes or configuration changes. • If silence detection is the cause, I can suggest safe thresholds and examples of where to change the logic so SIP users aren’t inadvertently muted or disconnected during egress. If you prefer, paste a short excerpt of the server/egress logs around one cutoff (timestamps and any audio/VAD/egress errors). That will speed diagnosis. Sources: Using a transformer to improve end of turn detection | LiveKit | How to detect and handle silence during calls | Agents Framework | livekit/livekit_composite | DeepWiki | How to implement call greeting retries in voice agents | LiveKit | How to detect and handle silence during calls | LiveKit, with interactive elements