I am using LiveKit Cloud to do a PoC (Azure Speech for STT and TTS, Azure OpenAI gpt-4.1-mini as LLM), the room is automatically close in every 5 mins, could that because of the limitation of FREE plan? If I upgrade to upper plan, do they have session limitations?

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

The close reason code is 10. Here are the console logs: [LiveKit] Room state → connecting at 2026-03-21T092856.554Z index-YeDgLbO4.js:86 publishing track {room: ‘consult-paediatrics-1774085334619’, roomID: ‘’, participant: ‘patient-Alex’, pID: ‘PA_EyyXiF449V58’, trackID: undefined, …} index-YeDgLbO4.js:88 [LiveKit] Room state → connected at 2026-03-21T092858.046Z index-YeDgLbO4.js:88 [LiveKit] Room state → disconnected at 2026-03-21T093356.765Z index-YeDgLbO4.js:88 [LiveKit] Room disconnected reason=10 at 2026-03-21T093356.765Z u @ index-YeDgLbO4.js:88 ZE.l.emit @ index-YeDgLbO4.js:50 emit @ index-YeDgLbO4.js:86 handleDisconnect @ index-YeDgLbO4.js:86 (anonymous) @ index-YeDgLbO4.js:86 ZE.l.emit @ index-YeDgLbO4.js:50 client.onLeave @ index-YeDgLbO4.js:86 handleSignalResponse @ index-YeDgLbO4.js:84 (anonymous) @ index-YeDgLbO4.js:84 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50Understand this warning index-YeDgLbO4.js:88 [App] Unexpected disconnect — rejoining room... (anonymous) @ index-YeDgLbO4.js:88 Y @ index-YeDgLbO4.js:88 ZE.l.emit @ index-YeDgLbO4.js:50 emit @ index-YeDgLbO4.js:86 handleDisconnect @ index-YeDgLbO4.js:86 (anonymous) @ index-YeDgLbO4.js:86 ZE.l.emit @ index-YeDgLbO4.js:50 client.onLeave @ index-YeDgLbO4.js:86 handleSignalResponse @ index-YeDgLbO4.js:84 (anonymous) @ index-YeDgLbO4.js:84 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50Understand this warning index-YeDgLbO4.js:86 could not createOffer with closed peer connection {room: ‘consult-paediatrics-1774085334619’, roomID: ‘’, participant: ‘patient-Alex’, pID: ‘PA_EyyXiF449V58’} (anonymous) @ index-YeDgLbO4.js:86 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 (anonymous) @ index-YeDgLbO4.js:50 _ @ index-YeDgLbO4.js:50 createAndSendOffer @ index-YeDgLbO4.js:86 (anonymous) @ index-YeDgLbO4.js:86 (anonymous) @ index-YeDgLbO4.js:50 _ @ index-YeDgLbO4.js:50 (anonymous) @ index-YeDgLbO4.js:86 $ @ index-YeDgLbO4.js:86 setTimeout gt.setTimeout @ index-YeDgLbO4.js:84 (anonymous) @ index-YeDgLbO4.js:86 b @ index-YeDgLbO4.js:86 (anonymous) @ index-YeDgLbO4.js:86 (anonymous) @ index-YeDgLbO4.js:50 _ @ index-YeDgLbO4.js:50 (anonymous) @ index-YeDgLbO4.js:86 xt @ index-YeDgLbO4.js:84 (anonymous) @ index-YeDgLbO4.js:86 (anonymous) @ index-YeDgLbO4.js:50 _ @ index-YeDgLbO4.js:50 negotiate @ index-YeDgLbO4.js:86 (anonymous) @ index-YeDgLbO4.js:86 (anonymous) @ index-YeDgLbO4.js:50 _ @ index-YeDgLbO4.js:50 (anonymous) @ index-YeDgLbO4.js:86 xt @ index-YeDgLbO4.js:84 (anonymous) @ index-YeDgLbO4.js:86 (anonymous) @ index-YeDgLbO4.js:50 _ @ index-YeDgLbO4.js:50 negotiate @ index-YeDgLbO4.js:86 (anonymous) @ index-YeDgLbO4.js:86 (anonymous) @ index-YeDgLbO4.js:50 _ @ index-YeDgLbO4.js:50 unpublishTrack @ index-YeDgLbO4.js:86 (anonymous) @ index-YeDgLbO4.js:86 handleDisconnect @ index-YeDgLbO4.js:86 (anonymous) @ index-YeDgLbO4.js:86 ZE.l.emit @ index-YeDgLbO4.js:50 client.onLeave @ index-YeDgLbO4.js:86 handleSignalResponse @ index-YeDgLbO4.js:84 (anonymous) @ index-YeDgLbO4.js:84 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50 Promise.then m @ index-YeDgLbO4.js:50 u @ index-YeDgLbO4.js:50Understand this warning index-YeDgLbO4.js:88 [LiveKit] Room state → connecting at 2026-03-21T093357.748Z index-YeDgLbO4.js:86 publishing track {room: ‘consult-paediatrics-1774085334619’, roomID: ‘RM_FjSmpP9QvAvL’, participant: ‘patient-Alex’, pID: ‘PA_6Fz3MD8M5bvm’, trackID: undefined, …} index-YeDgLbO4.js:88 [LiveKit] Room state → connected at 2026-03-21T093358.388Z index-YeDgLbO4.js:86 disconnect from room {room: ‘consult-paediatrics-1774085334619’, roomID: ‘RM_FjSmpP9QvAvL’, participant: ‘patient-Alex’, pID: ‘PA_6Fz3MD8M5bvm’} index-YeDgLbO4.js:88 [LiveKit] Room state → disconnected at 2026-03-21T093428.250Z index-YeDgLbO4.js:88 [LiveKit] Room disconnected reason=1 at 2026-03-21T093428.250Z

Thanks — this is really helpful context. I’m responding to your logs and the disconnect reason code (10) you shared. What the logs mean • Disconnect reason code 10 = CLIENT_INITIATED. That means the participant (or client code) explicitly left the room — it’s not a server-side timeout or a free-plan enforced 5‑minute limit. • Your logs show a clean connect at 092858 and a disconnect at 093356 — exactly five minutes later — which strongly suggests your app is calling leave()/disconnect() (or otherwise closing the PeerConnection) after 5 minutes. The later reconnect attempts and reason code 1 support that the client/app is managing the lifecycle rather than the platform forcing it. Plan impact • The Build (free) plan does not impose a 5‑minute per‑session hard limit. Upgrading increases quotas (concurrent sessions, monthly session minutes, WebRTC minutes) but does not introduce a fixed short session timeout that would close rooms every 5 minutes. Next steps to diagnose and fix (quick checklist) 1. Check client-side timers and cleanup code ◦ Search for

leave()

,

disconnect()

,

room.disconnect()

,

room.localParticipant.leave()

, or

ctx.shutdown()

and for timers like

setTimeout(..., 300000)

/

asyncio.sleep(300)

that may run after 5 minutes. 1. Inspect any reconnection logic or error handlers ◦ Your console shows “Unexpected disconnect — rejoining room...”; check what your reconnect handler does and whether it immediately triggers a cleanup if reconnection attempts fail. 1. Verify PeerConnection lifecycle on the client ◦ The message “could not createOffer with closed peer connection” indicates the PeerConnection was already closed when negotiation ran. Make sure you aren’t creating offers after a prior disconnect. 1. Check server/agent teardown or middleware ◦ If you have an agent process or middleware watching session age, confirm it’s not programmed to terminate sessions after a fixed period. 1. Use dashboard/logs to confirm who initiated the leave ◦ The LiveKit dashboard or server logs typically show whether the leave was CLIENT_INITIATED vs server-initiated. That will confirm the client triggered it. If you’d like, I can help further — two options: • Tell me which SDK/language you’re using (browser JS, React components, or a custom wrapper) and I’ll point to the exact places to search for a 5‑minute timer. • Paste the relevant parts of your connection/cleanup code (client entrypoint, reconnect handler, and any timeouts) and I’ll review them and suggest changes. You’re on the right track — this looks like application logic rather than a platform limit, and we can find the spot that’s calling the disconnect. Sources: Server-side | livekit/livekit_composite | DeepWiki | Agents on LiveKit Cloud | Deploy voice AI on global infrastructure | LiveKi... | LiveKit Platform | Build, run, and observe voice AI agents | LiveKit | Server lifecycle | LiveKit Documentation | Agent session | LiveKit Documentation, with interactive elements

Claude suggested remove the agent: true in this snip token.addGrant({ roomJoin: true, room: roomName, canPublish: true, canSubscribe: true, roomCreate: true, agent: true, }); And add disconnectOnPageLeave: false in the frontend code <LiveKitRoom key={roomKey} token={token} serverUrl={livekitUrl} connect={true} audio={true} options={{ disconnectOnPageLeave: false }} onDisconnected={handleDisconnected} style={{ display: “flex”, flexDirection: “column”, alignItems: “center”, width: “100%” }} > <AgentView onSummary={handleSummaryReceived} onEndSession={handleUserEndSession} /> <RoomAudioRenderer /> </LiveKitRoom> Do you agree?

Thanks — this is a great, clear next step. I agree with Claude’s suggestions and here’s why plus what to watch for. Why remove agent: true from the grant •

agent: true

is not a standard LiveKit grant field for video/room permissions. Including custom/unrecognized claims in the token can interfere with how your application interprets participant roles or lifecycle logic. • Removing it avoids unexpected side effects; only include claims the server or your own application explicitly checks for. Why set disconnectOnPageLeave: false • The default behavior (disconnectOnPageLeave = true) will disconnect the participant when the page unloads or is navigated away from, which can trigger room cleanup if no other non-agent participants remain. • Setting

disconnectOnPageLeave: false

prevents the client from automatically disconnecting on page leave/refresh, improving session continuity and avoiding unintended departure events. How these changes address the 5‑minute disconnect • Your logs showed disconnect reason 10 (CLIENT_INITIATED) exactly five minutes after connect, which means the client/app explicitly left. Removing a non-standard token claim and disabling automatic page-leave disconnect will eliminate two common causes of client-initiated leaves. • If some app logic (a timer or cleanup) was conditioned on an

agent

flag or page unload, these changes will stop that behavior. Additional checks to be safe • Search your code for explicit calls like

room.leave()

,

room.disconnect()

,

localParticipant.leave()

, or any

setTimeout(..., 300000)

/

asyncio.sleep(300)

and remove/adjust them if they’re unintended. • Confirm reconnect/cleanup handlers don’t immediately call leave if reconnection fails. Your logs show “could not createOffer with closed peer connection” — ensure offers aren’t attempted after a disconnect. • If you rely on server-side logic for agents, ensure any server-side lifecycle code isn’t shutting rooms down after a fixed interval. Suggested next steps 1. Remove

agent: true

from the token grant. Keep only the needed grants: ◦

roomJoin

,

room

,

canPublish

,

canSubscribe

,

roomCreate

(as required). 1. Set

disconnectOnPageLeave: false

in the

<LiveKitRoom>

options. 2. Test again and monitor logs. If you still see reason 10 disconnects, paste the relevant client connection/reconnect/teardown snippets and I’ll review them for timing or lifecycle calls. If you want, paste your token-generation snippet and the parts of your client reconnect/cleanup code and I’ll point out the exact lines to change. Sources: Avoiding Room ID Reuse When Re-Creating Rooms With the Same Name | server-sdk-kotlin | livekit/livekit_composite | DeepWiki | Server-side | livekit/livekit_composite | DeepWiki | Pricing | LiveKit | Pricing | LiveKit, with interactive elements

Awesome, the session can be longer than 5 mins now. I know LiveKit Cloud has spinning in Australia, when will you have the Agent in this region? Where I am keen to deploy my agent to.

Great — glad the session length issue is resolved! Answer to your region question • Australia is not currently available for Agent deployment on LiveKit Cloud. • LiveKit currently offers agent deployments in other regions (examples include US, EU, and AP regions like Mumbai), and the platform has media infrastructure that indicates future regional expansion is possible. What you can do now • If low latency to Australia is important, consider deploying in the nearest AP region (for example, Mumbai) to minimize latency while Australia region is not available. • I can help you evaluate latency and trade-offs between available regions if you tell me where your users are located (cities or ISPs you expect to serve). If you’d like, I can also: • Watch for updates and let you know when Australia becomes available, or • Help plan a rollout using the nearest existing region so you can begin deployment now. Which would you prefer — help testing latency from Australia to an AP region or assistance planning a temporary deployment while we wait for local region availability? Sources: Agents on LiveKit Cloud | Deploy voice AI on global infrastructure | LiveKi... | Build voice, video, and physical AI | LiveKit, with interactive elements

Watch for updates and let you know when Australia becomes available, We need to adhere to the compliance to make it deployed in Australia.

Thanks — I’ve noted that you want me to watch for Australia agent availability and that you must deploy in Australia for compliance. I’ll do two things for you: • I will monitor LiveKit Cloud region announcements and roadmap updates for an Australia agent region and let you know as soon as it becomes available. • I’ll also flag that your account / project requires Australia deployment for compliance, so when the region is launched I’ll remind you and can help with next steps for deployment and validation. In the meantime, a couple of practical suggestions while you wait for an Australia region: • Consider deploying to the nearest AP region (for example, Mumbai) for lower latency while you complete compliance planning and tests. • If data residency / compliance is strict, start documenting compliance requirements now (data residency, encryption at rest/in transit, access controls, audit/logging) so you’re ready to validate the Australia deployment once it’s available. Would you like me to: • Start periodic checks (I’ll notify you as soon as I see Australia listed), or • Notify you only once (single update) when it becomes available? Also, if you’d like, tell me any specific compliance controls or certifications you need (e.g., data residency, SOC2, encryption policies) and I’ll prepare a checklist you can use to validate the Australia deployment when it’s live. , with interactive elements

all of them data residency, encryption at rest/in transit, access controls, audit/logging. If you could notify me that will be great.

Thanks — this is very helpful. I’ll prepare the compliance checklist and watch for Australia agent availability for you. A few quick clarifying questions so I notify the right people and make the checklist accurate: 1. How would you like to be notified when Australia becomes available? ◦ Options: email address, Slack workspace/channel, webhook URL, or “notify me here” in this conversation. 1. Which LiveKit account or project should I associate this request with? ◦ Provide account ID, project name, or organization email so I can link notifications and the checklist to the correct project. 1. Which regulatory frameworks or certifications are required for your deployment? ◦ Examples: SOC 2, ISO 27001, HIPAA, GDPR, APRA (Australian Prudential Regulation Authority), or others. 1. Data residency specifics: ◦ Do you require that all data (media, recordings, transcripts, logs, metadata) remain physically in Australia, or only certain categories? ◦ Do you have a preferred cloud provider/region (e.g., Azure Australia, AWS ap-southeast-2)? 1. Encryption requirements: ◦ Do you need customer-managed keys (BYOK) for encryption at rest? ◦ Any specific algorithms, key rotation policies, or FIPS requirements? 1. Access control / identity requirements: ◦ Do you require SSO/SAML/OIDC, SCIM provisioning, strict RBAC, or restricted admin access? 1. Audit & logging requirements: ◦ Required retention period for audit logs? ◦ Do logs need to be exported to a specific SIEM or stored in-country? 1. Timeline / priority: ◦ Any deadline by which you must have Australia-based agents available? 1. Do you want the compliance checklist now to begin preparation, or only once the Australia region is released? If you prefer, just answer the notification method and the account/project ID for now and I’ll begin monitoring and prepare a draft checklist covering data residency, encryption at rest/in transit, access controls, and audit/logging. Once you confirm a few more details I’ll tailor the checklist to your exact compliance needs. , with interactive elements

via email pls - jay@enluma.health, we need to adhere to Privacy Act 1988, no cloud preference, If it’s in Sydney, it will be better.

Thanks — got it. I’ll notify you at jay@enluma.health when an Australia (Sydney) Agent region becomes available, and I’ll prepare a compliance checklist tailored to the Privacy Act 1988 covering data residency, encryption, access controls, and audit/logging. Below is the compliance checklist I’ll use to help you validate an Australia deployment. If you want any additions or tighter controls, tell me and I’ll update it before we begin monitoring. Compliance checklist for Privacy Act 1988 (prepared for Australia / Sydney deployment) 1) Data residency & residency scope • Confirm physical location of media and persistent data: ◦ Media traffic (real-time audio/video) — confirm it is hosted and terminated within Sydney data centers. ◦ Persistent recordings, transcripts, and derived data — confirm storage location is within Australia (Sydney). ◦ Metadata and user identifiers — confirm these are stored in Australia if required. • Confirm cross-border transfer rules and any third-party processing — require written assurance of no outbound transfers unless explicitly approved. • Confirm data deletion / retention controls to meet local retention requirements. 2) Encryption • In transit: ◦ All media and signaling must be encrypted in transit using TLS and SRTP (or equivalent). Confirm TLS versions and cipher suites supported. • At rest: ◦ Confirm recordings, transcripts, logs, and backups are encrypted at rest. ◦ Clarify key management: whether provider-managed keys or customer-managed keys (BYOK) are available; confirm support for rotation and key lifecycle. • Provide details on cryptographic standards used (e.g., AES-256 for storage, TLS 1.2/1.3). 3) Access controls & identity • Authentication: ◦ Support for SAML / OIDC SSO for admin access (if required). ◦ Strong multi-factor authentication (MFA) for administrative accounts. • Authorization: ◦ Role-based access control (RBAC) for admin and operator roles (least privilege). ◦ Separate production vs. development environments and accounts. • Secrets management: ◦ Ensure tokens/keys are revocable and expiry policies exist (short-lived tokens for users). ◦ Auditability of token creation and admin actions. 4) Audit, logging & monitoring • Audit logging: ◦ Capture admin actions, token issuance, room creation/deletion, participant join/leave events, and recording access. ◦ Ensure logs include timestamps, actor identity, and affected resources. • Retention & export: ◦ Confirm log retention period and the ability to export logs to an on-prem or country-located SIEM. • Tamper-evidence: ◦ Logs stored with integrity protections (append-only or immutability options) where possible. • Monitoring & alerting: ◦ Support for security alerts (suspicious activity, failed logins) and integration with your incident response processes. 5) Data handling & operations • Incident response: ◦ Confirm breach notification procedures and timelines compatible with Privacy Act obligations. • Data access requests: ◦ Process for subject access requests and procedures to retrieve or delete personal data. • Personnel & access: ◦ Background checks, least-privilege access for operations staff, and formal access approval processes. 6) Compliance evidence & certifications • Request copies of relevant certifications and attestations: ◦ SOC 2 / ISO 27001 reports (if available). ◦ Any local compliance statements for Australia. • Request a Data Processing Agreement (DPA) and details on sub-processors. 7) Technical validation tests to perform once Sydney region is available • Latency and media quality tests from your major user locations in Australia. • Verify storage location by creating sample recordings and confirming their region. • Validate TLS/SRTP cipher suites and key rotation workflows. • Test token expiry, revocation, and RBAC enforcement. • Export logs to your SIEM to validate retention and format. Next steps / confirmation • I will begin monitoring for Sydney (Australia) Agent availability and notify jay@enluma.health as soon as it’s announced. • I’ll keep this checklist ready and can tailor it to specific certificate/controls you require (e.g., SOC 2, ISO 27001, APRA requirements). • If you want, I can produce a short, 1‑page summary of the technical controls mapped to Privacy Act obligations for internal compliance review. Would you like the 1‑page technical-to-Privacy-Act mapping now, or wait until the Sydney region is announced? , with interactive elements

wait for the region is available. BTW: I know we could capture the audio history, where do the audio data being kept? Is that in Australia if I have spinning in AU?

Thanks — great question about where audio recordings are stored. Short answer • Right now, audio recordings are stored in the region where your LiveKit project’s storage is configured. If a Sydney/Australia Agent region is not yet available and you deploy to a different region (eg. Mumbai), recordings will be stored in that region unless you configure otherwise. • When a Sydney (Australia) Agent region becomes available and you deploy your agent there, audio recordings and persisted data can be kept in Australia if you configure project storage to use an Australia-based bucket or storage location. Details and options you can use to ensure audio data stays in Australia • Default project storage location: LiveKit persists recordings/transcripts to the project’s configured storage (cloud object storage). That storage location determines where the files physically reside. Confirm the storage region during project/agent setup. • Use an Australia-hosted storage bucket: If you need strict data residency now, you can configure LiveKit to write recordings to a customer-managed bucket in an Australian region (for example, an Azure or AWS bucket in Sydney). That ensures recordings are stored in Australia even if the agent is running in a nearby AP region. • Verify storage on test recordings: Once you have storage configured (or once Sydney region is available), create a short recording and verify its location/metadata to confirm it resides in the intended region. What I’ll do for you • I’ll notify you at jay@enluma.health when the Sydney/Australia Agent region becomes available. At that point I can help you: ◦ Confirm or change your project’s storage configuration to an Australia-based bucket, ◦ Run a short test to prove recordings and transcripts are stored in Sydney, and ◦ Walk through any storage encryption/key management settings you require (BYOK, rotation, etc.). If you want to prepare now • Tell me whether you prefer Azure or AWS (or no preference). I can provide the exact steps to configure a customer-managed Australian bucket and how to validate a sample recording’s residency so you’re ready as soon as Sydney is available., with interactive elements

The agent is hosted by myself at the moment, just wondering the audio storage.

Thanks — that’s a clear question and helpful context. I’ll respond to your point about self-hosting and where audio recordings are kept. Short answer • If you self-host the agent, LiveKit does not store audio data by default — all media stays in your infrastructure unless you explicitly enable recording/egress or Agent Observability. So right now, your audio stays wherever your self-hosted agent and your storage are configured. Details and what each option means for audio storage • Self-hosted agent (your current setup) ◦ Media (audio/video) flows through your servers/clients and is not stored by LiveKit unless you add recording or export functionality. You control where any persisted audio is written and how it’s secured. • If you enable Egress/Recordings ◦ Recordings are written to the storage you configure (your S3/GCS/Azure bucket). The storage region you choose determines physical residency — so you can store recordings in an Australia (Sydney) bucket if you configure it that way. ◦ If an upload fails and LiveKit’s backup option is enabled, temporary backup storage may be used (currently US-based) — check that behavior before relying on it for residency requirements. • If you enable Agent Observability (LiveKit’s observability feature) ◦ Observability session data, including audio used for debugging, is stored in LiveKit’s observability storage (currently US-based) and retained for a limited period (e.g., 30 days). That is NOT suitable if you require all persisted data to remain in Australia. What to do to ensure audio is kept in Australia when you need residency • Keep hosting the agent yourself and write recordings to a Sydney-based storage bucket you control (Azure/AWS/GCP in AP‑southeast‑2 or similar). This gives you full control over residency and encryption. • If you later migrate to LiveKit Cloud Sydney agents, configure project storage to a Sydney/Australia bucket so egress/recordings remain in‑country. After the region is available I can help validate this by creating and inspecting a test recording. • Avoid enabling Agent Observability (or confirm localized observability options) if observability storage in the US conflicts with your compliance needs. Security & compliance reminders (aligned with Privacy Act 1988) • Ensure recordings in your storage are encrypted at rest (AES‑256 or equivalent) and in transit (TLS/SRTP). • Control access with RBAC, short-lived tokens, and MFA for administrative accounts. • Maintain audit logs for recording creation/access and be prepared to export logs to your in‑country SIEM. Would you like: • Step-by-step guidance to configure egress to an Australia (Sydney) bucket now so you can test residency? • A short validation checklist I can run with you once you create a sample recording (to confirm region, encryption, and access controls)? I’ll also notify you at jay@enluma.health when Sydney agents become available and — when that happens — I’ll help verify recordings and storage residency. Which of the two options above would you like to do next? Sources: Privacy Policy | LiveKit | LiveKit Platform | Build, run, and observe voice AI agents | LiveKit | LiveKit Agent Observability | Debug and optimize voice agents | LiveKit | Streamline troubleshooting with Agent Observability | LiveKit | Backup Egress Recordings, with interactive elements

yes, I enabled Agent observability, is that possible to store the audio in our own blob storage, or GCS?

Thanks — good question, and I’ll answer exactly what’s possible right now and the practical alternatives you can use to meet your residency/compliance needs. Short answer • Agent Observability audio cannot currently be written directly to your own Azure Blob or GCS bucket automatically. Observability data (audio, transcripts, traces, logs) is stored in LiveKit’s observability storage in the US by default. • You can manually download session audio/transcripts from the dashboard or API and then store them in your own storage. Automatic export to customer-managed cloud storage is planned but not yet available. What that means for your compliance needs • Because Observability data lives in the US today, Agent Observability is not suitable if you need all persisted observability data to remain in Australia. • If you must keep all persisted audio in‑country, continue using your self-hosted agent and record/store audio directly to an Australia-based bucket under your control, or configure LiveKit Egress (for non-observability recordings) to write to your Australia storage. Practical options you can use now • Continue self-hosting the agent and store recordings directly to an Australia (Sydney) bucket you manage (Azure/AWS/GCP). This gives you full control over residency, encryption, and access controls. • Use the LiveKit dashboard/API to download observability session artifacts (audio/transcripts) and upload them to your Australia storage on demand or via an automated script. This is manual today but can be automated from your side. • For regular programmatic exports of conversation recordings (not observability), use LiveKit Egress to write recordings directly to your chosen cloud storage and region. Egress is the recommended approach for persistent recordings you want kept in-country. • Avoid enabling Agent Observability if any observability audio being stored in the US violates your compliance needs. You can disable per-session recording (

record=False

) or disable Observability at the project level. Planned improvements and monitoring • Automatic export of Observability data to customer-managed storage is planned (“coming soon”). I’ll notify you at jay@enluma.health when that feature or an Australia (Sydney) observability region becomes available. If you want, I can: • Provide a small script example to download session artifacts from the dashboard/API and upload them to Azure Blob or GCS (so you can automate interim exports). • Walk you through configuring self-hosted recordings to write directly to an Australia bucket. • Confirm specifically how to disable Observability for sessions so no US‑based audio is stored. Which of those would be most helpful right now? , with interactive elements