IVR
Purpose
Section titled “Purpose”Describe IVR: the automated menus that greet and route inbound callers, and how inbound DIDs reach them.
Overview
Section titled “Overview”Inbound numbers are routed by routing_rules (DID → destination), resolved
on the control plane so the edge stays dumb. A rule’s destination_type is one
of queue, extension, ivr, voicemail or ringgroup, optionally gated by a
business-hours schedule_id (with a separate closed-hours destination). The
resolver normalizes the DID, finds the active rule (falling back to the special
default DID), and returns a feature-code transfer target:
| Destination | Target |
|---|---|
| queue | *86<extension> |
| ivr | *87<extension> |
| ring group | *88<group> |
| voicemail | *99<mailbox> |
| extension | <extension> |
An IVR menu (ivr_menus + ivr_options) has a greeting, timeout/retry
behavior, and per-digit options whose action_type is queue, extension,
submenu or hangup.
Configuration
Section titled “Configuration”Menus and options are built in the tenant app (/api/v1/ivr-menus). Routing
rules map a DID (or default) to a destination; business hours come from the
business-hours endpoints.
Examples
Section titled “Examples”The IVR runner reacts to two parks. On *87<ext> it writes the menu config into
channel variables and runs play_and_get_digits; on the second park it reads the
pressed digit and dispatches the matching option — e.g. “Press 1 for Sales”
transfers to *86<sales-queue-ext>. Unmatched input falls through to the menu’s
timeout action.
- The inbound
did_dispatchdialplan sits before outbound routes so an inbound DID can never fall through to a carrier prefix and loop back out (toll- fraud guard). - A business-hours schedule fails open to the primary destination if no closed destination is set.