This message was deleted.
# ask-ai
s
This message was deleted.
t
Thanks for reaching out, Kevin. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
Thanks for reaching out! I’d love to help clarify how LiveKit Cloud handles concurrency limits, as it can be a bit tricky at first. • Participant concurrency: This is the total number of participants (both users and agents) connected across all rooms at the same time. For instance, the Build plan supports up to 100 participants, but if you need more, higher plans or custom setups can scale up to 100,000+ participants. • Session concurrency: This relates to specific services like agent sessions, ingress, or egress. For example, the Build plan allows 5 concurrent agent sessions, while paid plans offer higher limits, such as 20 on the Scale plan and 50+ on higher tiers. Since you’re looking at 200 concurrent calls, the participant concurrency limit is the key one to focus on. Don’t worry—you can request increases to these limits based on your plan. If you’d like, I’m here to help with scaling options or pricing details whenever you’re ready! Sources: Quotas and limits | LiveKit Docs | delay-handling/raw_data.txt | examples/voice_agents/llamaindex-rag/data/raw_data.txt | Cloud Architecture | LiveKit Docs | LiveKit Pricing
n
but will the end user get a unique call experience with the agent? how do I set it up to not create more sessions, and just add more participants?
t
I'm glad you're exploring ways to create unique call experiences for your users without the hassle of managing multiple sessions. Here's a friendly guide to help you navigate this: • Use participant identity and attributes: Try assigning unique identifiers and custom attributes, like user roles or preferences, to each participant. This helps in personalizing their experience beautifully. • Implement role-based logic: Tailor interactions based on these roles or attributes. For instance, an agent might respond differently to a "caller" compared to a "support" participant, making the conversation flow naturally. • Leverage Remote Procedure Calls (RPC): This is a nifty way for participants to trigger specific actions on others within the same session—like a caller interacting directly with an agent. • Configure RoomIO for targeted processing: If you’re using AI agents, you can set them up to focus on audio or interactions from particular participants only, ensuring responses feel personal and spot-on. By setting things up this way, you can easily scale by adding more participants without juggling new sessions, all while keeping the experience tailored and seamless. If you'd like, I'm here to help you dive deeper into any of these steps—just let me know! Sources: Inside a session | LiveKit Docs | examples/rpc/index.ts | How to set a fixed participant for agent audio processing
n
because we created 1 agent in livekit than loads the agent (our agent) configuration when the user call based on the attributes, in this case how will I manage session creation so I don't get a concurrent limit but rather a participant limit but each participant get their own experience, is this even possible?
t
Absolutely, you can definitely manage session creation in a way that respects concurrent session limits while still offering each participant a unique and personalized experience. Let me walk you through how you can make this happen: • Use participant attributes: When participants join a room, you can pass along user-specific data like agent configuration, language, or role. This helps you tailor their experience without the need to create new sessions. • Create per-participant agent sessions: For every participant, you can dynamically set up an agent session that handles their audio or interactions independently. This way, each person gets personalized responses, all while keeping within your concurrency limits. • Leverage event listeners: By using events such as
participant_connected
and
participant_disconnected
, you can effectively manage the lifecycle of these agent sessions on the fly. • Use RPC for inter-participant communication: This allows participants to trigger specific actions on others (like a user interacting with an agent) within the same room, enhancing interaction. • Record participants individually: Utilizing Participant or TrackComposite Egress lets you record specific participants or tracks, ensuring each user’s recording is kept separate and clear. This method helps you scale smoothly by adding participants instead of spinning up new sessions, all while delivering those personalized experiences your users will appreciate. If you'd like, I’m here to guide you step-by-step through any of these processes—just let me know! Sources: Rooms, participants, and tracks | LiveKit Docs | OpenAI Realtime API and LiveKit | LiveKit Docs | Inside a session | LiveKit Docs | Workflows | LiveKit Docs | examples/rpc/index.ts