https://livekit.io logo
Join Slack
Powered by
how inbound trunk and dispatch rule relate to each...
# ask-ai
b
how inbound trunk and dispatch rule relate to each other
✅ 1
t
Thanks for reaching out, Jupiter. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
Thanks — you're asking how an inbound trunk and a dispatch rule relate. Here's the short, practical answer. • Inbound trunk is the entry point for SIP/PSTN calls into LiveKit — it owns phone numbers, authentication, IP allowlists, and other provider-level settings. • Dispatch rule is the routing policy tied to one or more inbound trunks. It decides what happens to an incoming call (for example: create a unique room like 
call-{uuid}
, route to a named room, require a PIN, or match by called number). • How they connect: a dispatch rule references a trunk’s 
sip_trunk_id
. When a call arrives on that trunk, LiveKit evaluates the dispatch rules associated with that trunk and applies the matching rule to route the call into the appropriate room/flow. • Practical implication: you can have multiple dispatch rules for a single trunk to handle different numbers or routing behaviors; a dispatch rule won’t work unless it points to an existing inbound trunk. If you want, tell me your use case (per-number routing, PINs, or always-create-new-room) and I’ll suggest a dispatch-rule pattern. Sources: Layered Caller Verification for LiveKit SIP Calls | LiveKit | Agents telephony integration | LiveKit Documentation | Creating SIP Inbound Trunks and Dispatch Rules with Python SDK, with interactive elements
b
how many dispatch rule pattern
t
Good question — there are three dispatch rule patterns: • SIPDispatchRuleIndividual — create a unique room per incoming call (e.g., 
call-{uuid}
). • SIPDispatchRuleDirect — route every call to a specific named room (optionally PIN-protected). • SIPDispatchRuleCallee — route calls based on the called number (multi-tenant / per-department routing). Which pattern are you planning to use or want an example for? Sources: Layered Caller Verification for LiveKit SIP Calls | LiveKit, with interactive elements
b
difference between SIPDispatchRuleIndividual and SIPDispatchRuleCallee
t
Thanks — you’re asking for the difference between SIPDispatchRuleIndividual and SIPDispatchRuleCallee. Here’s a clear comparison. • Purpose ◦ Individual: Creates a new, unique room for each incoming call (isolated session per call). ◦ Callee: Routes calls based on the called number so different phone numbers map to different rooms or routing behaviors. • Typical use cases ◦ Individual: One-on-one support calls, IVR sessions where each caller gets an isolated room (e.g., 
call-{uuid}
). ◦ Callee: Multi-tenant or departmental routing—send calls to sales vs. billing based on which DID was dialed. • Room naming & behavior ◦ Individual: Room name is generated per call (prefix + unique id). Each call gets its own room lifecycle. ◦ Callee: Room can be chosen or configured per called number (stable mapping for that number). • When to choose which ◦ Use Individual when you need isolation per call or ephemeral sessions. ◦ Use Callee when routing must depend on the destination number (different teams, features, or policies by DID). Would you like an example configuration for either pattern? , with interactive elements
b
with individual, can I configure to accept every calls coming ?
t
Yes — SIPDispatchRuleIndividual can be configured to accept every incoming call. How to ensure it accepts all calls: • Associate the dispatch rule with the inbound trunk (
sip_trunk_id
in 
trunk_ids
). • Set 
dispatch_rule_individual
with a 
room_prefix
(e.g., 
"call"
). • Do not set 
inbound_numbers
filters or a 
pin
requirement. With no filters, the rule will accept all calls arriving on the linked trunk and create a unique room per call (e.g., 
call-{uuid}
). Would you like a concrete example payload or the SDK call for creating this rule? , with interactive elements
b
each dispatch rule will have an agent name right
t
You're asking whether each dispatch rule has an agent name. Short answer: no — agent assignment is optional. • A dispatch rule does not automatically include an agent name. • If you want automatic agent dispatch, add agents in the rule's 
room_config.agents
(each entry uses 
agent_name
). • You can list multiple agents for a rule, or leave the agents array empty to route calls without auto-dispatch. • The 
agent_name
must match the agent server's configured 
agent_name
so the correct agent is dispatched. Would you like an example JSON or SDK call showing a dispatch rule with agents? Sources: Agent dispatch | LiveKit Documentation | Avoiding crosstalk when multiple developers share a LiveKit project | LiveK... | Layered Caller Verification for LiveKit SIP Calls | LiveKit | Layered Caller Verification for LiveKit SIP Calls | LiveKit | Agent Builder | LiveKit Documentation, with interactive elements
b
what is auto-dispatch when you say leave the agents array empty?
t
Good question — by “auto‑dispatch” I mean agents automatically joining rooms when a dispatch rule runs. • If the dispatch rule's 
room_config.agents
array is empty, no agents are automatically dispatched. The call will create a room and the SIP participant will join, but an agent will not be started unless you trigger one later (API, token, or external trigger). • To have an agent join automatically, include one or more entries in 
room_config.agents
with matching 
agent_name
values. • There is no implicit fallback agent — empty = no auto assignment. Would you like a JSON example showing both cases (with and without agents)? Sources: Agent dispatch | LiveKit Documentation | Agents telephony integration | LiveKit Documentation, with interactive elements
b
what is "list multiple agents for a rule"?
t
“List multiple agents for a rule” means you put more than one agent entry in the dispatch rule’s 
room_config.agents
array so several agents will be automatically dispatched when that rule triggers. What that looks like: • Each entry includes an 
agent_name
(must match the agent server config). • You can dispatch multiple human or AI agents to the same room (simultaneous or in a priority order depending on your agent logic). Example JSON:
Copy code
"roomConfig": {
  "agents": [
    { "agentName": "primary-agent" },
    { "agentName": "supervisor-agent" }
  ]
}
Common uses: • Have a primary agent handle the call while a supervisor or analytics agent also joins. • Provide fallback or escalation by listing multiple agents (you can control who speaks/acts via agent logic). Would you like an example showing prioritized or conditional dispatch behavior? , with interactive elements
2 Views
Open in Slack
PreviousNext
Powered by