Asterisk PJSIP contact keeps switching reachable and unreachable

Name the exact contact and each state transition

Record the Asterisk version, endpoint, AoR, contact ID and URI, whether the contact is static or created by inbound registration, the first and last transition times, timezone, reported state and round-trip value. An endpoint label can summarize several contacts; a change on one URI is not proof that the whole endpoint, phone or trunk disappeared.

Asterisk's ContactStatus event can report Unknown, Unreachable, Reachable, Unqualified, Removed and Updated, while ContactStatusDetail exposes the contact URI, registration expiration, Via address, Call-ID, Path, User-Agent, qualify interval, timeout, proxy and response policy. Preserve the sequence instead of keeping only the final pjsip show contacts snapshot.

Separate contact churn from qualification failure

A dynamic contact can be updated or removed because registration state changed, its expiry elapsed, a device refreshed from a different source address, or the AoR's contact-limit policy selected an older entry for removal. That is a different event from an existing contact becoming unreachable after an OPTIONS qualification timeout. Compare contact ID, URI, Via, Call-ID, expiration and event type across the transition.

Current res_pjsip documentation explains that rewrite_contact can produce a different contact address on refresh and that max_contacts, remove_existing and remove_unavailable interact when the new registration would exceed the limit. Do not raise max_contacts, enable removal or disable rewriting merely to clear a label; first prove whether the same device created multiple contact identities and what another contact would displace.

Reconstruct one complete OPTIONS transaction

When qualification is enabled, preserve one successful and one failed cycle: DNS answers and lookup time, selected proxy and destination, outgoing OPTIONS, response or timeout, status code, source address, RTT and the resulting ContactStatus event. Asterisk documents that DNS lookup time is included in qualify_timeout. A late or missing response can therefore reflect the resolver, route, stateful firewall, NAT mapping, device, proxy or response path; the status alone does not select one.

qualify_frequency of zero means the contact is not periodically qualified. qualify_2xx_only is version-sensitive and changes whether only 2xx OPTIONS responses count as available. Confirm the exact loaded build and AoR values before interpreting a non-2xx response or changing policy. A response that is unacceptable under the loaded policy is different from no response.

Measure timing before changing timers

Compare several bounded cycles at the same contact and path. Retain the configured interval and timeout, observed RTT distribution, DNS duration, packet loss if independently captured, device sleep or reboot times and any coincident WAN or proxy change. One high RTT sample is evidence for one transaction, not a service-level result.

Do not lengthen the timeout until you know which stage consumed it. A larger timeout can mask a resolver or routing fault and delays detection of a genuinely lost contact; a shorter frequency creates more traffic and can interact with device, firewall or provider policy. Record the proposed effect, success criterion and rollback before one controlled change.

Use bounded runtime evidence and protect it

Read the loaded objects first, then enable protocol logging only for a short authorized window that covers an expected transition. Asterisk's troubleshooting guide recommends verbose, debug and PJSIP logger controls for a failing scenario, while its logging guide treats the result as a diagnostic artifact. Turn logging back off, retain only the relevant interval and protect it because SIP traces can contain numbers, identities, IP addresses, Contact and Route data, SDP and authentication material.

For longer observation, an authorized AMI consumer can retain ContactStatus events with URI, AoR, endpoint and RTT. The global send_contact_status_on_update_registration option controls additional update-registration events; it does not repair reachability. Monitoring must not change the contact policy it is meant to measure.

core show version
pjsip show endpoint <endpoint>
pjsip show aor <aor>
pjsip show contacts
pjsip show contact <contact-id>
core set verbose 4
core set debug 4
pjsip set logger on
# Observe one expected transition, then stop the capture.
pjsip set logger off
core set debug 0
core set verbose 0

Verify registration, reachability and calls separately

After a demonstrated correction, confirm that the intended contact remains present across at least one registration refresh and several qualification cycles, the expected response policy is loaded, and no unrelated contact was removed. Then place one authorized call and follow its INVITE, response, SDP and media. A Reachable contact can reject or misroute a call, and a completed SIP exchange can still have media failure.

Keep outbound-registration status separate: pjsip show registrations describes Asterisk acting as a registering client, while this investigation follows an AoR contact and its qualification state. In FreePBX-managed systems, change the owning GUI or module rather than generated PJSIP files. No PBX, endpoint, AoR, contact, registration, DNS result, proxy, network path, qualify transaction or call was tested for this guide.

Preserve the event type before comparing status labels

Asterisk 22 uses Unqualified in the ContactStatus change event and NonQualified in ContactStatusDetail. Preserve the event and field name, then correlate URI, time, RTT, DNS and proxy evidence through the qualification guide.