How to Set Up Asterisk Realtime Architecture with a Database Backend

Asterisk Realtime lets configuration (extensions, endpoints) be dynamically loaded from a database rather than static configuration files — enabling programmatic management and dynamic scaling. This guide covers this architecture.

Why Realtime Architecture Matters at Scale

Traditional flat-file configuration requires an Asterisk reload for changes to take effect, and becomes unwieldy for managing genuinely large numbers of extensions programmatically — Realtime architecture stores configuration in a database, queried dynamically, enabling much more scalable and programmatic PBX management.

When Realtime Is Genuinely Warranted

Appropriate for scenarios with many extensions (hundreds+), frequent configuration changes, or genuine need for programmatic extension management (see How to Set Up Multi-Tenant PBX Hosting for a scenario where this often applies) — adds real complexity, so smaller/simpler setups may not need this beyond standard flat-file configuration.

Step 1 — Set Up a Database for Realtime

See How to Install PostgreSQL and Configure It for Production Use or MySQL/MariaDB setup guides — Asterisk Realtime supports several database backends via ODBC or native database connectors.

Step 2 — Create the Realtime Schema

CREATE TABLE ps_endpoints (
    id VARCHAR(40) PRIMARY KEY,
    transport VARCHAR(40),
    context VARCHAR(40),
    allow VARCHAR(200)
);

Asterisk expects specific schema for Realtime-managed PJSIP endpoints — consult current Asterisk documentation for the exact required schema, since this can vary somewhat between Asterisk versions.

Step 3 — Configure ODBC Connection

[asterisk-connector]
Description = Asterisk Realtime Connection
Driver = PostgreSQL
Database = asterisk_realtime
Servername = localhost

Step 4 — Configure sorcery.conf for Realtime Backend

[res_pjsip]
endpoint=realtime,ps_endpoints
auth=realtime,ps_auths
aor=realtime,ps_aors

Tells Asterisk to use the Realtime (database) backend for PJSIP endpoint configuration, rather than reading from static pjsip.conf entries.

Step 5 — Managing Extensions Programmatically

INSERT INTO ps_endpoints (id, transport, context, allow) VALUES ('1005', 'transport-udp', 'internal', 'ulaw,opus');

New extensions can now be added via direct database insertion (or, more typically, through an application built on top of this database) — no Asterisk reload required for the new configuration to take effect.

Building a Management Application on Top of Realtime

See How to Build and Secure a REST API on a VPS — a common pattern builds a proper management API/application on top of the Realtime database, providing a genuine interface for extension provisioning rather than direct database manipulation.

Understanding the Trade-Offs

Realtime adds genuine database dependency and complexity — a database issue now directly affects PBX configuration availability in ways flat-file configuration doesn't; weigh this operational complexity against the genuine scalability/programmability benefits for your specific use case.

Combining Realtime with Traditional Configuration

Asterisk supports mixing Realtime and static configuration for different configuration sections — consider whether a hybrid approach (Realtime for frequently-changing extension data, static configuration for stable system-level settings) fits your needs better than converting everything to Realtime.

Common Errors

New database entries don't take effect despite correct insertion — verify your sorcery.conf mapping is genuinely correct for the specific configuration type, and check ODBC connectivity is functioning (test the connection independently of Asterisk to isolate whether the issue is database connectivity or Asterisk-specific configuration).

Continue Reading

Browse more articles in VoIP & Communication Servers.

مكتبة الشروحات

أقسام الشروحات

أقسام الشروحات