I have my own backend service running which has wh...
# ask-ai
g
I have my own backend service running which has whatsapp callng wehbook url, so we have text and voice endoint there itself - we arelady human agent - human agent in whatsapp calling but what we want now is we want stt agent orcestration an dtts layer and if i keep orchestration layer spearately it adds extra latency so does livekit itself can conncet with my backend serve via webrtc and handle transport layer and agetns layer?
✅ 1
t
Thanks for reaching out, Mamlesh. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
Thanks — I’m responding to your question about whether LiveKit can connect to your backend via WebRTC and handle transport + agent (STT/TTS) so you avoid an extra orchestration hop and added latency. Short answer: Yes. LiveKit can connect to your backend over WebRTC and handle media transport and agent orchestration so you can run STT/TTS without adding a separate high‑latency orchestration layer. What you can do next (options): • Connect your backend as a programmatic participant using a LiveKit server SDK. Your service joins the room, receives the voice stream over WebRTC, runs STT/TTS, and publishes audio back — no extra HTTP round trips. • Build an agent process using the LiveKit Agents framework. Agents join rooms as participants, stream audio to STT/TTS plugins, and return audio in real time. Agents are designed for low-latency voice AI pipelines. Why this reduces latency: • Media flows over WebRTC (UDP-based SRTP) via the SFU/peer paths instead of tunneling via extra HTTP layers. • STT/TTS can run inside the agent/process that’s directly connected to the room, avoiding an extra orchestration hop. If you want, tell me: • Which server language/SDK you’ll use (Node, Python, Go, etc.), and • Whether you prefer to run STT/TTS inside your existing webhook service or as separate agent workers. I’ll give you concise next steps and example code for your chosen approach. Sources: An open source stack for real-time multimodal AI | LiveKit | An open source stack for real-time multimodal AI | LiveKit | OpenAI and LiveKit partner to turn Advanced Voice into an API | LiveKit | Introduction | LiveKit Documentation | Speech-to-text (STT) models overview | LiveKit Documentation, with interactive elements
g
currently i have my backedn in typescript but is it possible to build that livekit in python or node? this is how my architecutre is backend (server) typesciprt - webrtc - livekit (agents)
t
Thanks — I’m responding to your question about whether you can run LiveKit agents in Python or Node while your backend is TypeScript. Yes. LiveKit agents can be built in both Node.js/TypeScript and Python. Your TypeScript backend can keep handling token generation, room lifecycle, and your WhatsApp webhook, while agents (in Node or Python) join LiveKit rooms as programmatic participants to run STT/TTS and return audio in real time. Next steps — pick one and I’ll give examples: • If you want agents in TypeScript/Node, I can show how to use the
@livekit/agents
SDK and a sample agent that subscribes to audio, streams it to STT, and publishes TTS. • If you want agents in Python, I can show the equivalent Python agent setup and deployment steps. Which language would you like example code for? Sources: Introduction | LiveKit Documentation, with interactive elements
g
how to handle that rooms, token generation - can you share some documents on that asepct and how can i write a wrtc
t
Thanks — I’m responding to your request about room handling, token generation, and writing a WebRTC client (
wrtc
) to connect your TypeScript backend to LiveKit. Below are concise steps, docs, and short TypeScript examples you can use. Key docs • Token generation & auth: https://docs.livekit.io/frontends/build/authentication/custom/ • Server SDKs (room management & tokens): https://docs.livekit.io/server/ • JS/TS client (WebRTC): https://docs.livekit.io/client-sdk/js/ 1) Generate access tokens (server-side, Node/TypeScript) • Use
livekit-server-sdk
to mint JWTs with room permissions. Example:
Copy code
import { AccessToken, VideoGrant } from "livekit-server-sdk";

const at = new AccessToken("API_KEY", "API_SECRET");
at.identity = "user-123";
const grant: VideoGrant = { room: "my-room", roomJoin: true, canPublish: true, canSubscribe: true };
at.addGrant(grant);
const token = await at.toJwt();
2) Room management (optional server-side control) • Rooms are created when the first participant joins, but you can create/list/delete rooms via
RoomServiceClient
. Example:
Copy code
import { RoomServiceClient } from "livekit-server-sdk";

const svc = new RoomServiceClient("https://your-livekit-host", "API_KEY", "API_SECRET");
await svc.createRoom({ name: "my-room" });
3) WebRTC client (browser / Node with
wrtc
): connecting to LiveKit • Use
livekit-client
in browser/Node. In Node you can use the
wrtc
package for WebRTC internals. Browser example:
Copy code
import { Room } from "livekit-client";

const room = new Room();
await room.connect("wss://your-livekit-host", token);
// publish local tracks or listen for remote audio
Node (headless) example with `wrtc`: • Install:
npm install livekit-client wrtc
Copy code
import { Room, createLocalAudioTrack } from "livekit-client";
import wrtc from "wrtc";

const room = new Room({ WebRtcAdapter: { RTCPeerConnection: wrtc.RTCPeerConnection } } as any);
await room.connect("wss://your-livekit-host", token);
// create/publish an audio track (e.g., from file or mic pipeline)
const localTrack = await createLocalAudioTrack();
await room.localParticipant.publishTrack(localTrack);
4) Connecting your TypeScript backend + Agents • Your TypeScript backend can: ◦ Generate tokens and manage rooms/webhooks. ◦ Either host Node agents using
@livekit/agents
or call out to Python agents — agents join rooms as participants and run STT/TTS. • Agents can be implemented in Node/TypeScript (use
@livekit/agents
) or Python (official agent SDKs). Next step • Tell me whether you want a full example: (A) TypeScript agent that subscribes to audio + uses an STT/TTS plugin, or (B) a headless Node
wrtc
client that bridges your WhatsApp webhook audio into a LiveKit room. I’ll provide the code you choose., with interactive elements
g
okay now - lets sya i am getting 10 calls is it possible that each call have its own configuration basically 1st call will have stt and tts as deepgram and 2nd call might havea stt as openai and tts as deepgram - is that a possiblty that we can have? and how deos room works for each call we will have a room or ? if that is the case is the rooms are configurable?
t
Thanks — responding to your questions about per-call STT/TTS, rooms, and configurability. Short answers: • Yes — each call can have its own STT and TTS configuration (e.g., call‑1 uses Deepgram STT + Deepgram TTS; call‑2 uses OpenAI STT + Deepgram TTS). • Typically you map one LiveKit room per call. Rooms are isolated and the agent/session for that room can be configured per call. • Rooms are configurable per call via dispatch rules, metadata, token-embedded config, or programmatic room creation. How to implement (high level): • When a call arrives, determine the STT/TTS choice (caller metadata, rules, DB lookup). • Create or name a room for that call (e.g., call-id) and include the chosen config as metadata or dispatch settings. • Dispatch an agent (Node or Python) to join that room and instantiate an AgentSession with the specific
stt
and
tts
providers for that session. • The agent processes audio in real time and publishes TTS back into the room. Ways to pass per-call config: • Dispatch metadata (readable by the agent when it starts). • Token/room configuration (embed agent settings in the token). • Programmatic agent startup (your backend calls dispatch API with config). If you want, I can: • Show a short example of dispatching a room with metadata and reading it inside an agent (TypeScript or Python). • Or provide a sample AgentSession snippet that switches STT/TTS per call. Which example would you like? Sources: Speech-to-text (STT) models overview | LiveKit Documentation | External data and RAG | LiveKit Documentation | Layered Caller Verification for LiveKit SIP Calls | LiveKit | Agent dispatch | LiveKit Documentation | Layered Caller Verification for LiveKit SIP Calls | LiveKit, with interactive elements
g
okay which llm is faster in execution? is having a rag is good thing in voice ai?
t
Good questions — I’ll respond to both parts: LLM speed and whether RAG is useful for voice AI. LLM speed (execution / time‑to‑first‑token): • Faster models are smaller/distilled variants — they give lower time‑to‑first‑token (TTFT) and so feel more responsive in voice flows. • Examples of faster options: OpenAI GPT‑4.1 mini / GPT‑4o (~200ms TTFT) and Gemini Flash‑Lite (~100ms for input processing). Larger models (full GPT‑4/Gemini 2.5 Flash) are slower (~200–350ms+). • For voice agents, prefer models that stream tokens so TTS can start as soon as the first tokens are produced. Is RAG good for voice AI? • Yes — RAG is recommended when you need grounded, domain‑specific, or personalized responses. It improves factual accuracy and relevance. • Tradeoffs: RAG adds retrieval work and can increase TTFT slightly, but the accuracy gains usually outweigh the small latency cost for knowledge‑heavy tasks. • Best practice: use RAG selectively (e.g., only for queries that need external data), cache frequent retrievals, and stream retrieval + LLM output so TTS can start sooner. If you want, I can: • Recommend specific model choices for a low‑latency voice pipeline, or • Show how to add RAG into an AgentSession (example in TypeScript or Python). Which would you prefer? Sources: Voice Agent Architecture: STT, LLM, and TTS Pipelines Explained | LiveKit | Voice Agent Architecture: STT, LLM, and TTS Pipelines Explained | LiveKit | Build Your First AI Voice Agent in Python: Complete Tutorial | LiveKit | Build Your First AI Voice Agent in Python: Complete Tutorial | LiveKit | https://livekit.com/pricing.md|, with interactive elements
g
• Recommend specific model choices for a low‑latency voice pipeline, or yes recomned me stt and tts also i want tamil, english, malay and andarin wilbe 4 most used lanuages in our scope which model is best for this in stt and tts - i want human liek voice 0 i know custom voice is there but which one is good
t
Thanks — responding with concise recommendations for STT, TTS, and LLM choices for a low‑latency multilingual voice pipeline (Tamil, English, Malay, Mandarin), plus short implementation notes. STT (recommended) • Primary: Deepgram Nova‑3 (multilingual) — best balance of low latency, accuracy, and automatic language detection for Tamil, English, Malay, Mandarin. Use
language="multi"
or explicit language hint when known. • Alternative / lower cost: Cartesia Ink Whisper — wide language coverage and good accuracy for low‑resource languages. • Implementation note: stream STT (real‑time) so transcripts arrive incrementally for turn detection and LLM streaming. TTS (recommended) • Primary: ElevenLabs Eleven Multilingual v2 — most natural, human‑like voices across many languages; good for Tamil, English, Malay, Mandarin. • Alternative: Rime Arcana — high quality, good multilingual switching and expressive voices if ElevenLabs isn’t suitable. • Implementation note: prefer streaming/low‑latency TTS with eager token→audio playback and prebuffer small chunks so audio starts quickly. LLM (recommended) • Fast / low‑latency: OpenAI GPT‑4o or GPT‑4.1 mini (use a distilled / streaming‑friendly variant). These give low time‑to‑first‑token and stream well into TTS. • Implementation note: choose a model that supports streaming output so TTS can start on first tokens; use smaller/distilled models for the strictest latency budgets. RAG guidance (brief) • RAG is recommended when you need factual, domain or user‑specific answers. It improves accuracy but adds some retrieval latency — mitigate with caching, selective retrieval, and parallel retrieval+LLM streaming. Deployment tips for low latency • Co‑locate agents/LLM/STT/TTS regionally near your users (reduce RTT). • Stream at each stage (STT → partial transcript → LLM streaming → TTS streaming). • Use smaller/distilled models for quick TTFT for routine prompts; fall back to stronger models for complex queries. • Use language hints / VAD to reduce unnecessary processing and to trigger quicker turns. If you want, I can: • Provide a short AgentSession example in TypeScript or Python wiring Deepgram + GPT‑4o + ElevenLabs for these languages. Which language (TypeScript or Python) do you prefer for the example? Sources: Build a multilingual voice agent that automatically switches languages | Li... | Deepgram STT | LiveKit Documentation | Speech-to-text (STT) models overview | LiveKit Documentation | Building Performant Voice Agents in India | LiveKit | Build voice, video, and physical AI | LiveKit, with interactive elements
g
in livelit how to define a rag - will it be tool call or agent or how will it work?
t
Good question — in LiveKit you can implement RAG in two main ways: as an LLM-invoked tool (on-demand retrieval) or as part of the agent lifecycle (pre- or post-turn retrieval). Both are first‑class patterns and can be combined. Short overview • Tool call (LLM-driven): Expose a retrieval function as a "tool" the LLM can call during generation. The LLM invokes the tool with a query; your tool returns retrieved passages, and the LLM continues generation using those results. Good for targeted retrieval during a turn. • Agent hook / prefetch: Run retrieval in an agent lifecycle hook (e.g., on_user_turn_completed or on_user_turn_started), fetch relevant documents, and inject them into the prompt/context before calling the LLM. Good for predictable queries or to avoid extra RTT during generation. • Hybrid: Prefetch likely documents in hooks and also expose a retrieval tool for ad‑hoc deep dives. How it maps in LiveKit • Tools: Implement a tool plugin or utility the agent can call from the LLM step. The LLM uses tool invocation to fetch external knowledge, then resumes streaming tokens to TTS. • Hooks: Use pipeline hooks (on_user_turn_started, on_user_turn_completed, or custom nodes) to run retrieval, enrich context, and set AgentSession state so the LLM sees the retrieved content when it runs. • Metadata & dispatch: Per-call metadata can guide which knowledge source to use (tenant DB, vector index, customer docs). Practical notes • Keep retrieval fast: use a vector DB with fast ANN queries (FAISS/Chroma/Pinecone/Weaviate), precompute embeddings, and cache frequent queries. • Control prompt size: inject only top-K passages and add source citations. Use snippet summarization if passages are long. • Streaming: If you prefetch, the LLM can stream tokens immediately to TTS. If using a tool call, implement the tool so its latency is low and consider streaming partial results. • Where to run: Retrieval can run in the agent process (recommended) so data is local to the job and latency is minimized. • Example switch: Use dispatch metadata to select index A vs B (e.g., product_docs vs legal_docs) per call. Small example patterns • Hook approach (pseudo): a. on_user_turn_started -> query vector DB with user query/context b. inject top-K passages into system prompt c. call LLM -> stream tokens -> TTS • Tool approach (pseudo): a. LLM receives prompt + tool spec b. LLM decides to call tool("retriever", query) c. your retriever returns passages d. LLM resumes and generates final answer using returned passages If you want, I can provide a concise code example (TypeScript or Python) showing: • a hook-based RAG injection into AgentSession, or • an LLM tool implementation + how to register/use it in a LiveKit agent. Which example would you like? , with interactive elements
g
okay i have rag implemnted in other places - is it psosible to call that? form agent.py via an endpoint
t
Yes — you can call your existing RAG endpoint from an agent (e.g., agent.py). Two common patterns: • Hook (preferred for low-latency prefetch) ◦ In a lifecycle hook (e.g.,
on_user_turn_started
or
on_user_turn_completed
), make an HTTP call to your RAG endpoint, get top‑K passages, and inject them into the prompt/context before calling the LLM. • Tool (LLM-invoked retrieval) ◦ Expose your RAG as a callable tool. Register a tool interface the LLM can call during generation; when invoked, the agent calls your endpoint, returns passages, and the LLM continues generation. Practical notes • Use a fast HTTP client (e.g.,
httpx
or
requests
in Python). Keep responses small (top‑K, pre-summarized) to limit prompt size. • Ensure the agent process can reach your endpoint (network, DNS, auth). If agents run in containers, allow outbound access or place the endpoint in the same VPC. • Cache frequent queries and return source IDs for traceability. • If you need streaming results into the LLM/TTS pipeline, return incremental snippets or call the retrieval in parallel with LLM start (prefetch + tool hybrid). Quick Python sketch (hook style):
Copy code
import httpx

async def on_user_turn_started(ctx):
    query = ctx.user_utterance
    async with httpx.AsyncClient(timeout=5.0) as client:
        res = await client.post("https://your-rag.example/search", json={"q": query, "k": 5})
        passages = res.json()["passages"]
    # inject passages into system prompt or session state
    ctx.session.prompt_add_context(passages)
Tell me which pattern you prefer (hook vs tool) and whether you want a full agent.py example showing the HTTP call + prompt injection (TypeScript or Python). , with interactive elements
g
what is the per min cost should be for a call
t
I’m responding to your question about per‑minute cost for a call on LiveKit (agent + STT/LLM/TTS + audio). Below is a concise estimate, cost drivers, and next steps. Estimated example cost (per minute) • Agent session: $0.0100/min • WebRTC audio (audio‑only): $0.0010/min • STT (Deepgram Nova‑3 Multilingual): $0.0077/min • LLM (e.g., GPT‑4.1 mini / small streaming model): $0.0015/min • TTS (high‑quality voice like Cartesia/ElevenLabs-ish): ~$0.0300/min Estimated total ≈ $0.0502 per minute Key cost drivers & variability • Model choice: STT and TTS dominate per‑minute costs; switching to cheaper models lowers cost substantially. • Plan tier: Scale plan offers lower inference prices than Build/Ship plans. • Usage patterns: Average spoken words/minute, TTS character count, and LLM tokens affect totals. • Regional hosting & co‑location can affect inference latency but generally not pricing directly. Cost optimization tips • Use distilled / faster LLMs for most turns, escalate to larger models only when needed. • Cache or reuse RAG retrievals to reduce LLM calls. • Choose lower‑cost STT for low‑critical calls and Deepgram/Cartesia/ElevenLabs for premium calls. • Measure average chars/min to estimate TTS charges precisely. Would you like: • a detailed per‑model cost sheet for your expected traffic, or • an optimized cost + quality configuration for Tamil/English/Malay/Mandarin? Sources: Deploy and scale agents on LiveKit Cloud | LiveKit | Build Your First AI Voice Agent in Python: Complete Tutorial | LiveKit | Pricing | LiveKit | Build voice, video, and physical AI | LiveKit, with interactive elements