Asterisk PJSIP_DIAL_CONTACTS: dial every current AoR contact

Name the endpoint, AoR and contact separately

A PJSIP endpoint holds call policy and can reference one or more address-of-record objects. An AoR owns permanent or dynamically registered contacts, while each contact supplies a concrete destination URI and runtime state. Record those names and relationships before changing dialplan logic.

PJSIP_DIAL_CONTACTS() requires an endpoint name. It can take one explicit AoR; if that argument is omitted, the function uses the AoRs configured on the endpoint. An optional request user changes the request URI user and should be supplied only when the peer or routing policy requires that exact identity.

Snapshot the contact set at the call decision

The function returns a properly formatted dial string for all contacts on the selected AoR set. Treat that return value as a call-time snapshot, not a permanent device list. Dynamic registrations can expire or be replaced, and permanent contacts can coexist with them.

PJSIP_AOR(name,contact) returns permanent and dynamic internal contact IDs separated by commas. Use PJSIP_CONTACT() on those IDs when URI or status detail is needed. Redact user parts, public addresses and Path information before placing evidence in a shared ticket.

Pass one generated dial string into Dial

Store the generated string, branch explicitly when it is empty and pass the non-empty value to Dial() with a bounded timeout. Do not wrap the returned string in an additional PJSIP/ prefix or replace it with a single endpoint target when the requirement is to ring every current contact.

Keep the generated string, the actual outbound channel names and the dialplan branch in one timestamped trace. A correct-looking value does not prove that every channel was created or that every destination accepted its INVITE.

Interpret parallel legs and the first answer

Dial() can request multiple channels. When one requested channel answers, Asterisk bridges that channel to the originator and hangs up the other requested channels. A cancelled sibling leg is therefore not automatically a device failure.

Record each destination, provisional and final SIP response, answer identity, cancel or hangup cause and final DIALSTATUS. Keep those per-leg facts separate from the whole call outcome and from the later media path.

Keep qualification separate from call acceptance

AoR fields such as qualify_frequency, qualify_timeout and qualify_2xx_only govern OPTIONS qualification. max_contacts, remove_existing and remove_unavailable govern registration inventory. None proves that an INVITE will be authorized, routed, alerted or answered.

A reachable contact can still reject a call, and an unqualified contact can remain in the generated set depending on the runtime configuration and state. Diagnose the contact inventory and the actual call legs rather than replacing registration policy to mask a dialplan error.

Validate lifecycle changes without widening scope

In an authorized test environment, register the intended devices, capture the AoR and contact snapshot, place one bounded call, identify the winning and cancelled legs, then repeat after one registration expires or is deliberately removed. Prove that the generated destination set changes as expected.

Do not raise max_contacts, disable replacement policy or add a static contact merely to make the test pass. Correct the first demonstrated mismatch between endpoint, AoR, contact inventory, generated string and outbound channels. No PBX, contact set or call was tested for this guide.

Inspect contacts separately from the generated dial string

Use the AoR/contact inspection guide to distinguish object fields and identifiers from the dial string generated by PJSIP_DIAL_CONTACTS().

Separate endpoint policy from contact expansion

Use the PJSIP endpoint guide to preserve endpoint policy and association before PJSIP_DIAL_CONTACTS() generates destinations.

Inspect inherited headers on every dialed contact

When one AoR expands to multiple contacts, the inheritable-header diagnostic treats every callee and emitted request as separate evidence.

Do not reuse call dialstrings as unexamined MESSAGE routes

The PJSIP MessageSend guide documents endpoint, AoR, contact and dialstring-like destination forms for an out-of-dialog MESSAGE. A dial-contact result for calls does not by itself prove message-method support or presentation.

Keep parallel contact legs attached to their own outcomes

The Dial application guide separates the generated dial string, created channels, first answer, losing-leg causes and final application status.

Place contact expansion behind an explicit membership owner

The DIALGROUP guide keeps named membership distinct from the current PJSIP contact dial string it may expand.