I have a workflow where I have a reservation platf...
# ask-aie
early-butcher-66889
03/10/2026, 10:16 PMI have a workflow where I have a reservation platform that sets up a room and dials outwards using a trunk to call a person to confirm their restaurant reservation. The issue is that we now want to include a recording for auditing purposes so that restaurants can review the transcript + the recording. We have everything implemented but the recording but we note that the recording currently can only be forwarded to S3? Our AWS security does not allow us to record to an S3 bucket directly using AWS key ID as we need to use OIDC for SOC2 purposes. What are other ways we can operate to ensure we can get the recording - do we stream the call live and have a service that records and writes on our behalf?
t
tall-airline-16756
03/10/2026, 10:16 PMThanks for reaching out, Arthur. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
tall-airline-16756
03/10/2026, 10:16 PMThanks — this is a great description of the problem. I’m responding to your question about alternatives to writing egress recordings directly to S3 with AWS access keys, and how you can meet SOC2/OIDC requirements.
Short answer: You don’t have to record directly to S3 with long‑lived keys. The simplest options are (1) stream the audio out of LiveKit via WebSocket (Track Egress) to your OIDC‑authenticated backend and let that backend record/store the files, or (2) push the egress as an RTMP stream into your own ingest service which records and stores using your OIDC workflows. If you are an Enterprise customer, LiveKit also supports S3 uploads using AssumeRole (temporary credentials), which can meet your security needs.
Options with pros/cons and what to consider
• Track Egress -> WebSocket to your backend (recommended for audio-only use)
◦ What it is: LiveKit sends raw audio frames (pcm_s16le) over a WebSocket to an endpoint you control.
◦ How it meets your needs: Your backend (already OIDC‑authenticated) receives the stream, writes the file (WAV/MP3/etc.), runs transcription, and stores artifacts in whatever compliant storage you use.
◦ Pros: Full control of storage and credentials, recordings never require LiveKit to hold your AWS keys, easy to integrate with your OIDC flows, low latency for live transcription/processing.
◦ Cons: WebSocket egress currently supports audio tracks (not arbitrary video/composite formats). You must implement the receiver to assemble frames into a file and handle reconnection/formatting.
• Room/Track Composite -> RTMP into your own ingestion service
◦ What it is: Egress outputs a single RTMP stream to an RTMP endpoint you host (media server/FFmpeg endpoint in your VPC).
◦ How it meets your needs: Your ingestion service receives RTMP, records (FFmpeg or media server), and stores using OIDC. Good when you need a single composed recording (mixed audio +/- video).
◦ Pros: Works for composite outputs, leverages existing media tools for recording/encoding, keeps storage inside your infrastructure.
◦ Cons: More infrastructure (RTMP server) to operate and scale. Slightly more complex to tie into real‑time processing pipelines.
• Enterprise: S3 uploads via AssumeRole / temporary credentials
◦ What it is: LiveKit uses temporary credentials (via AWS AssumeRole) instead of your long‑lived access keys to upload egress artifacts to S3.
◦ How it meets your needs: Removes the need to provide LiveKit with long‑lived keys; aligns better with your security posture.
◦ Pros: Less code to run on your side; familiar S3 workflow.
◦ Cons: This is an Enterprise feature. If you are Enterprise, this is a good compromise; if not, you’ll need one of the earlier alternatives.
• Client-side recording and upload
◦ Why not: It’s fragile for an audit trail (may miss one side, depends on client reliability), and it’s typically not recommended for strict compliance/auditing scenarios.
Practical recommendations and next steps
1. If you only need audio and want full control: implement Track Egress -> WebSocket to your backend.
◦ Implement a secure WSS endpoint that accepts the binary PCM frames and writes to WAV/MP3.
◦ Use your existing OIDC flow to authenticate and authorize that backend for storage/transcription.
◦ Add logic to start egress when the outbound call is answered (listen for the call/participant Joined event or hook into your SIP/egress orchestration).
1. If you need a mixed audio/video or a precomposed stream: use RTMP egress into your ingestion service, and record with FFmpeg or a media server, then store via OIDC-authenticated processes.
2. If you’re an Enterprise customer and want simpler direct S3 uploads: enable S3 AssumeRole so LiveKit uses temporary credentials rather than your long‑lived keys.
If you’d like, I can help with the next technical steps:
• Outline a minimal WebSocket receiver (WSS) design that writes a WAV file from pcm_s16le frames and handles reconnections.
• Example RTMP ingest flow with FFmpeg commands to record/segment the stream and upload to your OIDC‑protected storage.
• Guidance on when to trigger egress so you only record once the outbound call is connected (webhook or SIP rule approach).
Which approach sounds closest to what you’d prefer (WebSocket receiver, RTMP ingest, or Explore AssumeRole)? If you pick one I’ll give a short implementation sketch and key things to watch for.
Sources: Universal Egress | server-sdk-js | livekit/livekit_composite | DeepWiki | examples/bank-ivr | livekit/livekit_composite | DeepWiki
e
early-butcher-66889
03/10/2026, 10:24 PMHow does the websocket approach work? Is it streamed from the WebRTC room or my agent? I'm asking as I want to understand what security structure I need to put into place
t
tall-airline-16756
03/10/2026, 10:25 PMThanks — that’s a great clarifying question. I’ll explain exactly where the audio comes from with Track Egress → WebSocket, and what security controls you should put in place.
What is being streamed and where it originates
• The audio is streamed from LiveKit’s egress service, which reads the audio track(s) from the WebRTC room (not from an individual agent’s device). In other words, LiveKit captures the room track(s) server-side and sends the raw audio frames over a WebSocket to the endpoint you provide.
• You tell LiveKit which track or composite to egress; LiveKit then connects to your WSS endpoint and pushes binary frames containing raw PCM audio (pcm_s16le).
Security implications — what you need to protect
• Your WSS endpoint is receiving raw audio directly from LiveKit, so it must be trusted and protected the same way you protect any ingestion of sensitive data (recordings, PII).
• Because LiveKit initiates the connection to your endpoint, you must ensure only legitimate egress connections are accepted and processed.
Recommended security controls
1. Use TLS/WSS
◦ Serve your endpoint using TLS and require secure WebSocket (wss://). This ensures encryption in transit.
1. Authenticate and authorize the egress connection
◦ Require a short-lived token, HTTP header, or URL-signed credential that LiveKit includes when connecting. Validate it on your backend and reject unauthorized connections.
◦ If possible, rotate/expire these tokens frequently. Prefer short-lived credentials rather than static secrets.
1. Validate the caller and context
◦ Include room identifiers, egress job ID, and expected track IDs in the token or connection metadata. Your backend should verify these match an expected active session before accepting and persisting data.
◦ Optionally, verify the source IP ranges if LiveKit publishes them (if available to you), as an extra layer.
1. Mutual TLS (mTLS) or client certs (optional, high assurance)
◦ For higher assurance, use mutual TLS so both LiveKit and your ingestion service present certificates. This prevents unauthorized clients from connecting even if they have a token.
1. Ingress rate and size limits
◦ Enforce request size limits, timeouts, and maximum recording length per job to protect against resource exhaustion.
1. Secure storage and access controls
◦ Immediately store recordings in your OIDC‑protected storage with strict ACLs.
◦ Encrypt at rest and enforce least-privilege access to transcripts and recordings.
1. Audit logging and monitoring
◦ Log egress job start/stop, token usage, and any authentication failures.
◦ Alert on unusual activity (e.g., many egress starts for the same room).
Operational considerations for assembly & reliability
• Frame handling: LiveKit streams raw PCM frames. Your receiver must concatenate frames and write a correct container (WAV/RAW) or pipe into an encoder (FFmpeg) to produce MP3/MP4.
• Start/stop timing: Start egress only when relevant participants are connected (e.g., when the outbound call is answered). Use your orchestration logic or webhooks to trigger egress.
• Reconnects and retries: Implement logic to handle dropped connections, resume where possible, and mark incomplete files for retry or discard.
• Metadata: Accept metadata (room name, participant ID, egress job ID) so you can link recordings to reservations and audit trails.
Example minimal flow (high level)
1. Your orchestration triggers LiveKit Track Egress with the WebSocket URL: wss://your-ingest.example.com/egress?token=shortlived
2. LiveKit connects over WSS and starts sending binary PCM frames for the requested track.
3. Your service validates the token and expected egress parameters, opens a writer or pipes to FFmpeg, and writes/encodes the recording.
4. On egress completion or hangup, LiveKit closes the connection; your service finalizes storage, runs transcription, and records audit logs.
If you’d like, I can:
• Provide a minimal example (pseudo-code) for a secure WSS receiver that converts
pcm_s16lee
early-butcher-66889
03/10/2026, 10:37 PMSo websocket security I can figure out - the last thing is how do I know the room is closed and we can just trigger a compile job on all received frames? I don't want to use the agent end call hook as WarmTransfersTask means that the call can continue - does the WebRTC room have their own hooks that signal the event?
t
tall-airline-16756
03/10/2026, 10:38 PMGreat question — I’ll explain exactly how to know when it’s safe to finalize (compile) the recorded frames, and why you should rely on room lifecycle events instead of agent call hooks.
Short answer
• Don’t use agent end-call hooks for finalizing recordings — they can fire while the room is still active (e.g., warm transfers).
• Use the room lifecycle webhook
room_finishedroom_finishedroom_finishedroom_finishedroom_finishede
early-butcher-66889
03/10/2026, 10:39 PMcan a webhook url be registered at the time of room creation? or is it set at the organisation level? we have many environments meaning that we need to do this at room create or by agent
t
tall-airline-16756
03/10/2026, 10:40 PMThanks — good question. I’m answering whether webhook URLs can be set per room or per agent (at room creation), and how to handle multiple environments.
Short answer
• Webhook URLs are configured at the LiveKit project level and apply to all rooms in that project. You cannot register a different webhook URL at room creation or per agent.
What that means for multi-environment setups
• If you need different webhook endpoints per environment (staging, prod, tenant, etc.), you have two practical options:
◦ Create separate LiveKit projects for each environment.
▪︎ Each project can have its own webhook URL and credentials.
▪︎ This is the cleanest separation for security and routing.
◦ Use a single project and route inside your webhook consumer.
▪︎ Keep one global webhook endpoint.
▪︎ Encode environment/tenant context into the room name or room metadata when you create the room.
▪︎ In your webhook handler inspect
room.nameroom.metadatae
early-butcher-66889
03/10/2026, 10:44 PMThis isn't feasible as we were told that we need to pay for additional plans per environment and therefore we have resorted to using one project for now. Is an alternate way to trigger the event on websocket close? I assume that if there is a reconnection event to write frames we can just recompile when that next connection closes?
t
tall-airline-16756
03/10/2026, 10:45 PMThanks — good constraints to call out. I’ll answer directly: yes, using the WebSocket lifecycle is a feasible fallback when you cannot rely on per-room webhooks, but you need to implement it carefully to be reliable and audit-safe.
Short answer
• You can use the WebSocket close event from LiveKit’s Track Egress → WebSocket to trigger finalization of the recorded frames.
• Do not finalize on every disconnect; only finalize on a confirmed end-of-stream (clean egress close) and handle reconnections so you don’t miss frames or double-process.
How to do this reliably (recommended pattern)
1. Correlate streams up front
◦ Include
egressIdroomNameegressIdstopEgressegress_endedroom_finishedegressIde
early-butcher-66889
03/11/2026, 12:01 AMI'm reading the egress request and I see that it is done on a participant level. How do I ensure that we start tracks for both the participant / the agent (and all subsequent joiners) and how do we ensure that we only trigger a job to join all tracks when all participants have left?
t
tall-airline-16756
03/11/2026, 12:01 AMThanks — that’s a clear, actionable question. I’ll explain how to start track egress for all participants (agent + joiners) and reliably trigger the final join/compile job only after everyone has left.
High-level approach
• Start a track egress job for each published participant track (agent and others) when that participant publishes.
• Track active participants server-side using webhooks (participant_joined / participant_left).
• Trigger your final merge/compile job only when the room becomes empty — use the room_finished webhook (or confirm all egress jobs ended via egress_ended) before compiling.
Step-by-step pattern
1) Start egress for every participant track
• Listen for the track/participant publish event (e.g.,
track_publishedparticipant_joinedparticipant_joinedparticipant_leftroom_finishedroom_finishedegress_endedroom_finishedegress_endedegress_endedegress_endedroom_finishedparticipant_joinedroom_finishedegress_endedroom_finishedroom_finishedegress_endede
early-butcher-66889
03/12/2026, 4:27 PMI have used egress - but I am setting tmp tokens - how long should these tokens last? How long does it take for egress to start the bucket upload?
t
tall-airline-16756
03/12/2026, 4:28 PMThanks — good questions. I’ll address both: how long your short‑lived (tmp) tokens should last, and when LiveKit begins uploading egress output to storage.
Short answers
• LiveKit’s egress service begins uploading to your configured storage as soon as the egress session starts (there isn’t a long startup delay).
• If you’re issuing temporary credentials that LiveKit (or an intermediary service) will use for uploads, make them valid for the expected egress duration plus a safety buffer — typically at least the maximum expected call length + 30–60 minutes.
Details and recommendations
1) When upload starts
• Uploads commence effectively when the egress job starts: the egress process boots, captures the media, and begins writing/streaming the output to the configured destination immediately. Plan for upload activity to begin right away once egress is initiated.
2) Token lifetime guidance
• If you are handing temporary credentials that are used by some service to store recordings, the credentials must remain valid for the entire time that egress might be active and for a short period afterward while finalization/commit completes.
• Practical recommendation:
◦ Token lifetime = expected maximum call/recording length + 30–60 minutes buffer.
◦ Example: if recordings can run up to 2 hours, issue tokens valid for ~2.5–3 hours.
• Why the buffer: finalization, encoding, multipart uploads, retries, or post-processing can extend beyond the raw media capture time.
3) If LiveKit is doing the upload directly
• You generally do not need to hand LiveKit ephemeral tokens for each job. LiveKit uses the storage credentials or role configuration you provide (or an enterprise AssumeRole setup) to perform uploads. Ensure whatever credentials/role LiveKit uses are valid for the job lifetime.
• For enterprises using temporary credentials (AssumeRole), ensure the role/session duration covers the egress job plus the same buffer above.
4) Failure and retry handling
• Design for retries and transient failures: if a token expires unexpectedly while an upload is in progress, multipart uploads or retries can fail. Having a buffer prevents this.
• Log and monitor egress failures related to authorization so you can detect if tokens are expiring too soon.
If you want, I can:
• Suggest concrete token durations based on your typical and worst‑case call lengths, or
• Describe how to implement an automated token/AssumeRole issuance flow that guarantees coverage for running egress jobs.
Which would help you more — a recommended table of token durations for common call lengths, or a sketch of an automated credential refresh/AssumeRole flow?
Sources: Security | LiveKit | Universal Egress | LiveKit
2 Views