Asterisk PJSIP AoRs and contacts: registration, limits and dialing

Keep endpoint, AoR and contact as different objects

A PJSIP endpoint supplies policy and channel behavior. Its aors relationship identifies one or more address-of-record objects. An AoR holds permanent contact URIs or admits dynamic contacts created by inbound REGISTER requests. A contact is the concrete URI Asterisk can try at that moment. Reusing those names as if they were one object hides where the failure actually lives.

Trace the chain explicitly: endpoint name, referenced AoR name, configured contact policy, current contact URI, transport and status. The Asterisk troubleshooting guide uses pjsip show endpoint <name> to expose the linked AoR and contact, then pjsip show aor <name> to verify the loaded AoR and its contact URIs. A configured endpoint with an empty AoR contact list has no destination even when authentication succeeded elsewhere.

Treat max_contacts as admission control

Asterisk documents max_contacts as the maximum number of dynamic contacts an AoR may bind through registration. It does not limit permanent contact= entries, concurrent calls, line keys, extensions, call starts or every physical phone in an organization. The count therefore answers a narrow question: how many current dynamic bindings can this AoR admit?

A REGISTER can still fail or displace another binding depending on the other AoR options. Count the loaded dynamic contacts and correlate their URIs, expiration times and source addresses before changing the maximum. Raising the number without identifying why contacts multiply can preserve stale NAT bindings or let unapproved devices remain reachable.

Understand replacement and cleanup together

When remove_existing is enabled and an update would exceed max_contacts, Asterisk removes enough existing contacts to accept the new one, beginning with the contacts that expire soonest. That can intentionally move service to a new binding, but it can also make a still-valid device stop ringing. remove_unavailable changes the selection when qualification data says a contact is unavailable and, when used without remove_existing, can remove unavailable contacts to make room.

These options depend on evidence that may not exist. A contact that has not been qualified is not proven unavailable. Expiry order is not device priority. Record the intended multi-device policy, qualification configuration and observed contact set before choosing automatic eviction.

Do not mistake a rewritten address for a second identity

With rewrite_contact, Asterisk rewrites the stored Contact URI host and port to the source address of the REGISTER request. This helps reach devices behind NAT, but a refreshed registration can arrive from a different translated port and temporarily look like a different contact. Asterisk warns that the changed address can cause the contact count to exceed max_contacts unless replacement behavior is designed for it.

Separate device identity, SIP user, Contact URI, received source address, transport flow and NAT binding. A changed port does not by itself prove another handset, and a stable user name does not prove the same network flow. Preserve both the REGISTER transaction and the resulting AoR contact list.

Keep registration, qualification and calling separate

A successful REGISTER creates or refreshes a contact binding. Qualification sends OPTIONS on its own schedule and reports contact state such as Reachable, Unreachable, Unqualified, Unknown, Removed or Updated. Those states do not prove authentication policy, an inbound ringing result, call answer, media flow or service availability.

Use the loaded contact URI and expiration to prove registration state, and the contact's round-trip and status fields to prove the qualification observation. Then place an authorized call only if call behavior is in scope. A contact can register but fail OPTIONS, answer calls while unqualified, or pass OPTIONS while a dialplan or media problem still prevents a usable call.

Choose first-contact or all-contact dialing deliberately

Asterisk's PJSIP dialing guide says Dial(PJSIP/endpoint) requests the first contact associated with the endpoint. To ring every registered contact, PJSIP_DIAL_CONTACTS(endpoint) builds an ampersand-separated dial string for simultaneous dialing. Adding another admitted contact therefore does not automatically make a custom dialplan ring it.

Decide whether the service should ring one selected binding, all current bindings or a managed hunt path. Preserve the generated dial string and the outbound channels it creates. Simultaneous dialing also needs explicit answer, cancellation, timeout, forwarding, voicemail and privacy behavior; the contact list alone does not define those outcomes.

Validate the Contact before storing a route back

A REGISTER's packet source and advertised Contact can differ. The PJSIP ACL guide keeps source permission, Contact permission, supported rewrite behavior and the stored AoR contact as separate evidence.

Turn the current contact set into an observable dial attempt

Use the PJSIP_DIAL_CONTACTS workflow when an endpoint must ring every current AoR contact. The generated string is a call-time snapshot; qualification, created channels and final SIP responses remain separate evidence.

Inspect the live contact objects behind an AoR

The PJSIP_AOR and PJSIP_CONTACT guide shows how the AoR contact field returns internal identifiers that can be resolved to URI, expiry, status and other contact fields.

Keep the endpoint profile separate from its AoR locations

The PJSIP endpoint guide shows how aors associates an endpoint profile with location objects without turning the endpoint itself into a dialable contact.

Keep Realtime AoR configuration and contact state separate

The PJSIP Realtime guide distinguishes the configured AoR object, related contact storage, cache model and runtime binding.

A contact candidate is not yet an outbound Dial channel

Use the Dial diagnostic to connect the selected contact to channel creation, signaling, answer and final status.

Do not flatten FreePBX report rows into one PJSIP object

When Asterisk Info and the CLI disagree, the focused diagnostic compares endpoint, AoR, contact, outbound registration and report transformation separately.

Choose the AMI list that matches the AoR question

The AMI inbound-registration guide separates broad AoR detail, dynamic-only contact status and all-contact snapshots.

Do not treat an endpoint contact field as contact detail

The AMI endpoint inventory guide separates associated contact text from registration, expiry and qualification evidence.

Distinguish AoR contact summaries from exact contact objects

The AMI AoR inventory guide keeps list contact text, static configuration and REGISTER-created bindings separate.