In a room composite egress the agents audio cuts out after some duration of the call and he seems to be mute in the recorded audio. however the agents was audible to the sip user at the other end and the agents audio is also present in the twilio recording.

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

1, yes audio output is true. 2. yes from session analytics the audio track remained published all the time. 3. Trackcomposite 4. No, doesnt happen after same duration

Thanks — that’s really helpful detail. You’ve confirmed: agent

audio_output=true

, the agent’s audio track stays published per session analytics, you’re using TrackComposite egress, and the cutout is intermittent (no fixed duration). I’ll help narrow this down. What I’m responding to • Your agent remains publishing audio, but the TrackComposite recording intermittently loses the agent’s audio while the SIP user and Twilio still have it. What to check next (these are targeted diagnostics that help pinpoint where the loss is happening) 1. Confirm the Track IDs used by egress ◦ Which track ID(s) did you supply to the TrackComposite egress for the agent audio? If egress targets the wrong track or a track instance that gets replaced during the session, the egress file can lose that audio mid-call. ◦ Please share the track ID from session analytics at a time when audio is present and one from when it’s silent. 1. Verify track lifetime vs. track replacement ◦ Some clients republish audio tracks (new track IDs) during the call (e.g., on reconnect or device change). TrackComposite records the specific track ID(s) you give it and will not automatically follow a republished track. ◦ Can you confirm whether the agent client ever republished or re-created its LocalAudioTrack during the session? Server-side logs or participant track lists over time can show that. 1. Check egress worker logs for warnings/errors ◦ Look for any warnings or errors from the TrackComposite worker around the time audio drops (e.g., subscription failures, encoding errors, or track-not-found messages). ◦ If you can paste a short excerpt of the egress worker logs around a drop event, I can help interpret them. 1. Confirm subscriptions and participant routing ◦ Even if the track is published, the egress worker must subscribe to it. Verify the egress process remained subscribed to the agent’s audio track for the entire session (subscription state changes appear in server logs/analytics). ◦ If you have server-side events showing subscription/unsubscription for the egress worker, please share them. 1. Reproduce with a focused test ◦ Start a short test call where you: i. Start TrackComposite targeting the agent’s current audio track ID. ii. Have the agent speak intermittently and, if possible, intentionally trigger a reconnect or device change. iii. Note the exact times when audio appears in the room vs. when it disappears in the recorded file. ◦ Provide the timestamps and the egress logs collected for that test. Immediate workarounds • If the agent may republish audio tracks, use a small controller to: detect new agent audio track IDs and restart or update the TrackComposite egress to point to the new track ID. This ensures the egress follows the active audio. • As an alternative, consider running a Room-level track egress (subscribe to the participant rather than a single track ID) or a continuous mixer approach if you need resilience to track replacement. If you can share any of the following, I’ll give precise next steps: • The track ID(s) you provided to TrackComposite and a corresponding agent track ID timeline from analytics. • Relevant egress worker log excerpts around a drop event (timestamped). • Any client-side events indicating repro or track republish/replacement. Once you share those, I’ll help identify whether egress lost the subscription, was pointed at a replaced track, or hit an encoding/worker issue — and give exact config or code changes to resolve it. Sources: Universal Egress | LiveKit | Agents (Python) | livekit/livekit_composite | DeepWiki | Why is there extra audio at the end of my recordings of an agent session? |..., with interactive elements

the egress worker runs in livkit itself right?

Good question — yes, the egress worker runs as a separate service outside the core SFU/LiveKit process, but it is part of the LiveKit system (deployed and managed alongside LiveKit components). Short facts • Egress runs in separate worker processes (egress workers) rather than inside the SFU process. • Egress workers handle capture/transcoding and coordinate via Redis Pub/Sub with the rest of the system. • For RoomComposite, egress launches a headless Chrome instance and uses GStreamer/virtual audio devices to capture rendered audio/video; for TrackComposite it subscribes to specific tracks and exports them directly. Why this matters for your issue • Because egress is a distinct service, problems can stem from: ◦ The egress worker losing subscription to a specific track, ◦ The worker targeting a specific track ID that gets replaced, ◦ Local capture/transcoding issues inside the worker (e.g., headless Chrome/PulseAudio/GStreamer for RoomComposite). • Checking egress worker logs and subscription state is therefore important when diagnosing intermittent audio loss. If you’d like, I can: • Tell you what log entries to look for in the egress worker logs, • Provide the exact server-side events that show subscription/unsubscription for a track, • Suggest a quick test to confirm whether the egress worker lost subscription or the track was republished. Which of these would be most helpful right now?, with interactive elements