Asterisk PJSIP Realtime: Sorcery mapping, schema and cache boundaries

Name one exact object before choosing its storage

PJSIP configuration is composed of typed objects such as endpoint, auth, AoR, contact and identify. Record the configuration class, owning module, Sorcery object type and case-sensitive object ID before discussing a database row. An endpoint that references an AoR and auth is an object graph, not one interchangeable record.

Keep configuration presence separate from runtime state. An endpoint row can load while no contact is bound, no request has been identified, no registration has succeeded and no call has completed. Start acceptance with the exact object and behavior that the change is meant to supply.

Trace the complete Sorcery-to-database mapping

The Sorcery mapping selects a wizard for an object type. For PJSIP Realtime, that wizard points to a Realtime family such as ps_endpoints; extconfig.conf then maps the family to a driver, connection name and optional table. The ODBC connection name resolves separately through res_odbc.conf to a system DSN and driver. Preserve every name exactly.

A loaded res_pjsip, a Sorcery mapping, an extconfig.conf family, a connected ODBC resource and a matching database row are independent observations. Prove the chain in that order rather than treating the word realtime as a connection test.

Prepare modules and schema for the installed branch

The PJSIP Realtime tutorial requires the database connector to be available before dependent modules use it. Confirm module packaging, startup ordering and the exact owner of generated or managed configuration before changing files. A database that answers ordinary SQL is not proof that the required Asterisk connector and Realtime driver are loaded.

Use the schema delivered for the installed Asterisk branch and preserve its migration revision. Asterisk documents Alembic scripts for creating and updating Realtime tables and warns that jumping release series can risk data loss. Back up and rehearse migrations with the database owner; do not copy a later table definition into production or infer compatibility from a successful connection.

Choose source order and eligible object types deliberately

Sorcery can consult several mappings for the same object type. The PJSIP Realtime guide shows both Realtime and static pjsip.conf sources and states that line order controls which source is read first. Document whether mixed storage is intentional, which source owns each ID and how duplicate IDs are prevented.

Do not assume every PJSIP object is suitable for Realtime merely because a mapping can be written. The upstream tutorial explicitly warns that some object types can lead to errant behavior and identifies optional-module ownership for objects such as identify. Validate the installed branch, owning module and current documentation for each type.

Treat cache policy as part of configuration correctness

A Sorcery memory cache can sit ahead of Realtime. The documented defaults can retain objects indefinitely unless limits, expiry, stale lifetime or reload behavior are configured. Record cache name, mapping order, population mode and timestamps whenever comparing CLI output with a backend row.

Single-object caching and full-backend caching answer different access patterns. Asterisk notes that types often retrieved in sets, including contacts and identify objects, are poor fits for incomplete per-object caches; full_backend_cache changes that model by preloading the set. Cache expiration or population is an operational action, not evidence that the backing record or mapping is correct.

Accept storage, loaded object and behavior separately

Validate one approved object through schema row, Sorcery retrieval, the module-specific PJSIP view and the behavior it is meant to supply. For a related endpoint graph, inspect endpoint, auth, AoR, identify and contact state independently. Preserve an unaffected control object from the same intended source.

A row visible in SQL, a PJSIP object shown by CLI, a recognized request, a bound contact and a completed call are different checkpoints. Rehearse unavailable database, missing row, invalid field, duplicate source, stale cache and restart or reload behavior in an authorized non-production path. No object, cache, registration or call was tested for this guide.

Confirm that a file is actually the selected backend

The AMI configuration diagnostic checks the configuration owner and loaded mapping before treating UpdateConfig as authoritative.

Verify backend and objects after module load

The module capability diagnostic separates resource registration, configuration mapping and instantiated objects.