Asterisk ARI push configuration: Sorcery objects, storage and lifecycle

Define one exact Sorcery object

ARI exposes GET, PUT and DELETE on /asterisk/config/dynamic/{configClass}/{objectType}/{id} for one case-sensitive object identity. The current API documents these operations from Asterisk 13.5.0. Record the target Asterisk instance, exact configuration class, object type and ID before doing anything; res_pjsip, endpoint and alice are three separate path components, not an interchangeable label.

GET returns a list of attribute-value ConfigTuples. PUT creates or updates an object from a fields list and returns the resulting tuple list. DELETE removes the object. A tuple response is configuration evidence for that one object; it is not proof of the storage backend, cache state, endpoint registration, routing, media or a completed call.

Prove Sorcery support and the selected wizard

Push configuration applies only to modules whose objects are managed by Asterisk's Sorcery abstraction. Sorcery can map an object type through static configuration, AstDB, realtime, memory and memory-cache wizards, and it can consult multiple mappings in order. Inspect the effective sorcery.conf, loaded modules and object mapping for the exact class and type before attempting a mutation.

Asterisk warns that the standard static configuration-file provider supports retrieval but not object creation, update or deletion. The documented writable examples use memory, AstDB or realtime drivers. A successful GET therefore does not establish that PUT or DELETE is supported, and a 403 mutation failure is not a reason to overwrite pjsip.conf directly.

Validate fields, authorization and read-back

Use a narrowly authorized ARI identity over protected HTTP. A user configured as read_only=yes can service only GET and OPTIONS; a change client needs explicit, separately governed write authority. Keep credentials and secret-valued configuration out of URLs, long-lived logs and shared evidence.

Send only the approved non-default attributes for the known object schema. The API distinguishes a bad body (400), an unsupported or refused mutation (403) and an unknown configuration class or object type (404). After an accepted PUT, capture the returned full tuple set and perform an exact GET. Do not treat default-filled output as proof that every value came from the request or that a later consumer used it.

Create related PJSIP objects in dependency order

PJSIP commonly relates endpoint, authentication and AoR objects. Asterisk's push-configuration example creates auth and AoR before the endpoint because ARI can accept an endpoint that references objects that do not yet exist. That incomplete graph may be visible through configuration reads while inbound authentication, registration or contact storage still fails.

Model the entire intended object graph and validate each exact read before exposing it to traffic. Keep transport, identify, registration and contact objects distinct from endpoint, auth and AoR. The example order is not permission to create production credentials from an unreviewed template; use the installed version's object reference and a change-specific dependency plan.

Keep persistence, cache and activation separate

The selected Sorcery wizard controls where the object is written and how long it can survive. Asterisk documents memory for state that need not persist beyond reloads and AstDB for an example intended to survive restart; realtime and custom mapping behavior depend on their configured backend. Prove the actual record, reload result and restart recovery instead of assigning durability from the word dynamic.

A memory cache can return an older object after its backing store changes, depending on expiry, stale and populate policy. Preserve the cache mapping and observation time with every comparison. An ARI read-back, backend record and module-specific CLI view are three different observations; reconcile them before claiming that an update was ignored or applied.

Delete in safe dependency order and prove behavior

Deletion removes one exact Sorcery object and documents 403 when it cannot be deleted and 404 when the class, type or ID is absent. Asterisk's PJSIP example removes the endpoint before its AoR and auth so new requests stop using those related objects. Plan the reverse dependency order, active-session policy and rollback before deleting anything.

Acceptance includes the exact GET or absence, intended backend and cache state, module-specific CLI object, reload or restart lifecycle where required, one bounded affected registration or call flow and an unaffected control. Deleting configuration does not terminate every existing channel or erase external records. No object, credential, registration, call or deletion was tested for this guide.

Map the writable Realtime wizard before changing an object

The PJSIP Realtime guide traces Sorcery source order, Realtime family, connector, schema and cache before an ARI read-back is treated as persistent state.