Kamailio MI and RPC for AI Dispatcher Control in 2026

Kamailio is the SIP load balancer of choice in front of FreeSWITCH, Asterisk, and AI media servers because the dispatcher module is the closest thing telephony has to a Kubernetes service. The 2026 release adds multi-threaded TLS and tighter MI-over-RPC plumbing, so you can drain an AI media node mid-spike without dropping calls.

Background

Kamailio is a high-performance SIP proxy written in C, descended from SER and OpenSER. It is the canonical edge proxy for VoIP carriers and large enterprise PBXes. The dispatcher module load-balances SIP requests across a pool of backends with algorithms ranging from round-robin to weighted call-load to consistent hashing on Call-ID.

Management Interface (MI) is the legacy control channel: a FIFO file or a UDP socket that takes text commands like dispatcher.list or dispatcher.set_state. RPC is the newer JSON-RPC interface (HTTP, BinRPC, JSON-RPC over UDP) that exposes hundreds of commands across every module. The mi_rpc module bridges them so you can call MI commands via RPC and vice versa.

For AI voice the dispatcher pattern is everything. You have a fleet of media servers (FreeSWITCH boxes running mod_audio_stream, or LiveKit SIP gateways, or your own bridges); Kamailio fronts them and routes calls based on health, weight, and tenant policy. When a media server gets hot, you set its state to inactive over RPC and Kamailio drains it.

Architecture

graph LR
    A[Carrier SIP Trunks] --> B[Kamailio 6.1 Edge]
    B -->|dispatcher| C[Media Server 1]
    B -->|dispatcher| D[Media Server 2]
    B -->|dispatcher| E[Media Server N]
    F[Control Plane] -->|RPC| B
    F -->|kamcli| B
    G[AI Brain] -.->|MCP| F

The control plane talks to Kamailio over JSON-RPC on a private port (default 5060 with ctl module bound to /var/run/kamailio/kamailio_ctl). An AI brain or autoscaler can call dispatcher.set_state with a duid attribute to drain a destination, then dispatcher.reload after the database is updated.

# kamcli example: drain media-2 in group 1
kamcli dispatcher set-state inactive 1 sip:media-2.callsphere.local:5060
# verify
kamcli dispatcher list
# reload after DB change
kamcli dispatcher reload

CallSphere implementation

CallSphere does not deploy Kamailio in front of our production stack. Every call on every product (Healthcare AI on FastAPI :8084 to OpenAI Realtime, Real Estate AI, Sales Calling AI with 5 concurrent outbound, Salon AI, IT Helpdesk AI, After-Hours AI with 120-second simul call+SMS) terminates on Twilio Programmable Voice. Twilio handles SIP-side load balancing across their carrier interconnects; we receive WebSocket-flavored audio downstream. For self-hosted enterprise deployments asking for on-prem Kamailio, our engineering team has a reference Kubernetes Helm chart that pairs Kamailio 6.1 with FreeSWITCH media nodes and a control plane that calls dispatcher RPC from our existing 90+ tools across 115+ DB tables. Pricing for that managed-on-prem option starts above our $1499 tier and is quoted case by case. The 22% affiliate and 14-day trial apply to the standard SaaS only.

Build steps

1. Install Kamailio 6.1.2 on Ubuntu 24.04, enable mod_dispatcher, mod_jsonrpcs, mod_xhttp, mod_mi_rpc.
2. Populate the dispatcher table with your media servers, group ids, and weights.
3. Expose JSON-RPC on a private interface; lock down with iptables and a shared secret.
4. From your control plane (or the kamcli tool), call dispatcher.set_state to mark a destination inactive before drain, active after.
5. Use dispatcher.reload only after DB writes; the module rate-limits to one reload every 5 seconds by default.
6. Pair RPC commands with Prometheus exporter metrics so the autoscaler reacts to active call counts.
7. For multi-region, run one Kamailio per region and let DNS SRV pick; do not try to share dispatcher state cross-region.

Pitfalls

• Reloading dispatcher more than once every 5 seconds silently fails; bump ds_load_min_interval if your topology changes faster.
• Setting a destination inactive does not hang up live calls; it stops new traffic. Existing channels stay until natural hangup.
• mi_rpc is loaded but disabled by default in some Kamailio packaging; check modparam("mi_rpc","mi_rpc_path","").
• JSON-RPC over xhttp lacks auth by default; layer mTLS or basic auth on top.
• Dispatcher consistent-hash on Call-ID will reroute calls if a node dies; if your AI session has state, make sure your media server can recover or your dispatcher is sticky-on-failure.

FAQ

Is the FIFO MI still useful? For one-off shell scripts yes. For programmatic control RPC is cleaner because it returns structured JSON and supports HTTP transport.

How do I see all available RPC commands? kamctl rpc system.listMethods returns the full list. There are over 300 in a default Kamailio 6.1 build.

Does Kamailio handle media? No. Kamailio is signaling-only. Media goes through rtpengine or your media server (FreeSWITCH, Asterisk, LiveKit).

How fast is dispatcher reload? Sub-100 ms typical for tables under 1000 entries; larger fleets use database-backed dispatcher with on-demand row caching.

Can I drain a node and let in-flight calls finish? Yes. dispatcher.set_state inactive only blocks new calls; let active calls drain naturally, then take the node down.

Sources

• Kamailio v6.1.0 Release Notes
• DISPATCHER Module documentation
• MI_RPC Module
• kamcli tool on GitHub
• Kamailio as Asterisk Load Balancer - Sinologic

Start a 14-day trial to skip the SIP proxy entirely with our managed Twilio stack, see pricing for $149/$499/$1499, or contact us about on-prem Kamailio reference architectures.