ScaiDial

ScaiDial is the voice telephony product on top of ScaiGrid. You attach one or more SIP trunks from your carrier or PBX, configure dialplans that route incoming calls to extensions or bots, and get a working phone system without operating an Asterisk or FreeSWITCH yourself.

It is built on the same identity, accounting, and module surface as the rest of ScaiGrid. Every call is metered, every action is audited, every config change goes through the same admin API. ScaiDial is a peer of ScaiBot — when an extension routes a call to a bot, ScaiDial spawns the existing ScaiBot voice worker into the same LiveKit room. No new orchestration layer.

When to use it#

• You have a SIP trunk (ITSP, carrier, or in-house PBX) and want a programmable layer on top of it.
• You want calls to ring a ScaiBot voice agent for some routes and humans for others, with a dialplan deciding which.
• You want a web-based admin surface for trunks, extensions, dialplans, voicemail — not a .conf editing experience.
• You want your tenant users to manage their own DND, forwarding rules, and voicemail without admin intervention.
• You want click-to-call from a browser without running a desktop softphone.

If you only need outbound notification calls with no inbound routing and no dialplan, you can call your carrier's API directly. ScaiDial adds the dialplan engine, the multi-tenant boundary, the in-browser softphone, and the integration with ScaiBot voice.

What you get#

• Trunks. Register outbound to any SIP carrier or PBX. Auth by credentials or IP whitelist. Per-trunk sync state with retry on failure.
• DIDs. Map carrier-delivered numbers to dialplans.
• Extensions. Internal numbers that route calls to a user (wave), a bot (bot), a voicemail box, an external number, or a SIP endpoint.
• Dialplans. Visual rule builder — match by DID, extension, caller prefix, or time window; act by ring/forward/voicemail/play-message/hangup.
• Voicemail. Audio storage, optional transcripts (opt-in per tenant), web playback.
• Active call control. One-click hangup, hold/unhold, blind transfer over SIP REFER. Live observability of all calls in the tenant.
• Call history. Searchable record of every call, filterable by date, extension, caller, and end reason.
• In-browser softphone. Click-to-call from your owned extension to any E.164 number or SIP URI. WebRTC into a LiveKit room; SIP leg added via livekit-sip.
• End-user portal. /my/dial gives every tenant user their own extensions, voicemail, forwarding rules, and call history — no admin permission needed.

Two-minute mental model#

You manage four nouns and one verb:

• A trunk is a connection to a carrier or PBX. Calls leave through it; calls arrive via it.
• A DID is a phone number on a trunk that customers can dial.
• A dialplan is a sequence of if X then Y rules that decides what happens when a call arrives.
• An extension is a destination — a user line, a bot, a voicemail box, or an external forward.
• And the verb: a caller dials a number; ScaiDial routes the call through a dialplan to an extension, and either bridges the audio (human or bot pickup) or records it (voicemail).

Outbound is the same flow in reverse. The browser softphone or an admin originate request joins a LiveKit room; ScaiDial adds the SIP leg via livekit-sip; the trunk delivers the call to the carrier.

Where ScaiDial sits relative to ScaiBot#

• ScaiBot owns the conversational AI: prompt, voice cloning, the LiveKit worker that streams audio.
• ScaiDial owns the telephony: trunks, dialplans, the SIP leg, the active-calls surface.

When a dialplan routes a call to a bot extension, ScaiDial drops the SIP participant into a LiveKit room and asks ScaiBot to kick off its standard voice worker into the same room. The two products share the cluster config but nothing else at the API level.

What it doesn't do (yet)#

• Multi-trunk routing (LCR). The current outbound originate picks the oldest synced trunk per tenant. Pattern-matched LCR is a v1.1 follow-up.
• Attended transfer. Blind transfer ships in v1; attended (talk-then-transfer) lands later.
• Conference rooms. Two-leg calls only in v1.
• Per-voicemail-box configuration. Every extension currently shares one tenant-wide voicemail box.
• Inbound DTMF. Receiving DTMF tones from a caller during a bridge is on the roadmap; sending DTMF is implemented but admin-only.