--- title: "Kamailio Dispatcher for AI Voice Scaling in 2026: Round-Robin Is Not Enough" description: "Kamailio 6.0's dispatcher module is how you horizontally scale AI voice bridges behind a SIP front-end. Round-robin is the easy answer; call-load and weight-based dispatching is the right one." canonical: https://callsphere.ai/blog/vw3d-kamailio-dispatcher-ai-scaling-2026 category: "AI Infrastructure" tags: ["Kamailio", "Dispatcher", "Load Balancing", "AI Voice", "Scaling"] author: "CallSphere Team" published: 2026-04-09T00:00:00.000Z updated: 2026-05-07T09:59:38.213Z --- # Kamailio Dispatcher for AI Voice Scaling in 2026: Round-Robin Is Not Enough > Kamailio 6.0's dispatcher module is how you horizontally scale AI voice bridges behind a SIP front-end. Round-robin is the easy answer; call-load and weight-based dispatching is the right one. > A round-robin SIP dispatcher works for the first hundred concurrent AI calls. By call number 200 you discover that one bridge node has 80% of the GPU pressure and another has 10%. Kamailio 6.0's dispatcher does better, but only if you configure it past defaults. ## Background ```mermaid flowchart LR Phone["PSTN caller"] --> Carrier["Carrier"] Carrier -- "SIP INVITE" --> SBC["Session Border Controller"] SBC -- "SIP" --> PBX["Twilio / Asterisk"] PBX -- "RTP ยท Opus" --> Bridge["AI Voice Gateway"] Bridge --> AI["OpenAI Realtime"] AI --> Bridge Bridge --> PBX ``` CallSphere reference architecture Kamailio is a SIP server, not a media gateway; it routes signaling. The dispatcher module distributes SIP requests across a pool of downstream destinations using one of several algorithms: round-robin, hash over From/To/Call-ID, weight-based, call-load-based, and a few others. Kamailio 6.0 (released 2025) and 6.1 (2026) refined the call-load algorithm and added new health-check options. For AI voice in 2026, Kamailio fronts a fleet of bridge nodes (FreeSWITCH or your own FastAPI bridge) that each terminate calls and connect to OpenAI Realtime. The dispatcher picks which bridge gets the next call. Round-robin is the obvious default; under real production load with non-uniform call durations and tool-call-heavy conversations, it leaves bridges unbalanced. Call-load dispatching tracks active calls per destination and routes to the least-loaded node. ## Technical deep-dive ``` # /etc/kamailio/dispatcher.list 1 sip:bridge-1.callsphere.ai:5060;weight=10 1 sip:bridge-2.callsphere.ai:5060;weight=10 1 sip:bridge-3.callsphere.ai:5060;weight=8 1 sip:bridge-4.callsphere.ai:5060;weight=10 ``` ``` # kamailio.cfg snippet loadmodule "dispatcher.so" modparam("dispatcher", "list_file", "/etc/kamailio/dispatcher.list") modparam("dispatcher", "ds_ping_interval", 10) modparam("dispatcher", "ds_probing_threshold", 3) modparam("dispatcher", "ds_probing_mode", 1) route { if (is_method("INVITE")) { # Algorithm 9 = call-load (active calls per destination) if (!ds_select_dst("1", "9")) { # 8 = weight-based fallback ds_select_dst("1", "8"); } t_on_failure("FAIL_FALLBACK"); route(RELAY); } } failure_route[FAIL_FALLBACK] { if (t_check_status("5[0-9][0-9]")) { ds_mark_dst("ip"); # mark this destination as inactive ds_next_dst(); # try next t_relay(); } } ``` The call-load algorithm requires Kamailio to track active dialogs (mod_dialog) so it knows which node currently has how many calls. The weight-based algorithm uses static weights from the dispatcher list, which works if your nodes are heterogeneous (different vCPU sizes). For AI voice the additional knob is "tool-call density". A bridge node handling a Healthcare AI call with frequent EHR lookups consumes more CPU than one handling a Salon AI call that only books appointments. Pure call count under-counts that. A custom XHTTP route can let bridges report load back to Kamailio and feed a custom_dispatcher state table. ## CallSphere implementation CallSphere uses Twilio Programmable Voice across all six verticals; Twilio handles the SIP front-end and we do not run Kamailio in our default cloud SKU. For customers requiring on-prem multi-region (regulated Healthcare AI prospects, primarily), Kamailio dispatcher in front of FreeSWITCH bridge nodes is the documented architecture. Healthcare AI on FastAPI :8084, Real Estate AI, Sales Calling AI (5 concurrent outbound per tenant), Salon AI, IT Helpdesk AI, and After-Hours AI (Twilio simul call+SMS with 120-second timeout) would be served by a horizontally-scaled bridge fleet behind Kamailio in such deployments. Across 37 agents, 90+ tools, 115+ DB tables, HIPAA + SOC 2 alignment, $149/$499/$1499 pricing, 14-day trial, and 22% affiliate, the dispatch policy in those deployments uses call-load primary with weight fallback and active health checks. ## Implementation steps 1. Build a fleet of bridge nodes that each register with Kamailio (or are statically listed in dispatcher.list). 2. Set ds_ping_interval to 5-15 seconds with TCP/TLS pings; mark unhealthy nodes inactive within a minute. 3. Use algorithm 9 (call-load) primary for AI voice; calls vary in duration too much for hash-based to balance. 4. Set per-destination weights matching vCPU + GPU capacity; reset weights when scaling up. 5. Enable failure_route to retry on 5xx responses against the next destination automatically. 6. Configure mod_dialog so dispatcher can track active dialog counts. 7. Expose Kamailio dispatcher metrics via xhttp and scrape into Prometheus. 8. Pre-fetch capacity: at 90% bridge utilization across the fleet, scale up the auto-scaling group; do not wait until 100%. ## FAQ **Can Kamailio handle media too?** No. Kamailio is signaling only. Media goes to FreeSWITCH, RTPProxy, or directly between endpoints (depending on topology). **Does Twilio expose this kind of dispatch internally?** Twilio's edge does its own load balancing across their bridges. You do not see or tune it. **What about Kubernetes-native SIP?** Kamailio runs in Kubernetes fine; the harder part is keeping SIP UDP and TCP/TLS ports addressable through the LoadBalancer service. Use a NodePort or hostPort for SIP. **How many concurrent calls per Kamailio node?** A single well-tuned Kamailio handles tens of thousands of CPS and millions of concurrent dialogs. The bottleneck is almost always the bridges. **What is new in Kamailio 6.0/6.1?** 6.0 stabilized HTTP/2 client; 6.1 (2026) added improved dispatcher metrics and finer tlsf integration. KamailioWorld 2026 highlighted production deployments mixing dispatcher with WebSocket-backed mobile push. ## Sources - [Kamailio: DISPATCHER Module documentation](https://www.kamailio.org/docs/modules/6.0.x/modules/dispatcher.html) - [Sinologic: Kamailio as a Load Balancer for Asterisk - Practical Guide 2026](https://www.sinologic.net/en/2026-03/kamailio-as-a-load-balancer-for-asterisk-a-practical-guide-with-the-dispatcher-module.html) - [Sinologic: KamailioWorld 2026 Future of VoIP](https://www.sinologic.net/en/2026-04/kamailioworld-2026-what-will-be-presented-and-what-it-tells-us-about-the-future-of-voip.html) Start a [14-day trial](/trial), see [pricing](/pricing) for $149/$499/$1499 tiers, or [contact us](/contact) about scaled on-prem AI voice deployments. --- Source: https://callsphere.ai/blog/vw3d-kamailio-dispatcher-ai-scaling-2026