Define the exact stale transition
Record the monitoring phone, BLF key, target extension, expected context, displayed state, last known correct time and the transition that failed: idle to ringing, ringing to in-use, in-use to idle, hold or a user presence change. Confirm whether every watcher is stale or only one phone and whether every target is affected or only one hint.
Do not begin by recreating extensions or changing event packages. A lamp that was never populated, a lamp stuck after a call, an unknown state and a user presence label are different incidents. Preserve the Asterisk version, uptime, phone model and software, provisioning source and timestamps before reload or reboot removes the useful state.
Prove the provider and loaded hint first
Query the mapped device provider with DEVICE_STATE() or the relevant CLI and inspect the exact extension and context with core show hints. Confirm every provider joined by &, its current value, the aggregate extension state and watcher count. Use EXTENSION_STATE() only for an extension with a loaded hint in the intended context.
If the provider itself never changes, stay with channel-driver state generation, provider naming or the application that owns a Custom: value. If providers change but the aggregate does not, inspect the mapping and aggregation. If the hint and aggregate change correctly, stop editing dialplan and follow the notification path. A zero watcher count is subscription evidence, not a diagnosis of the provider.
Trace SUBSCRIBE acceptance as its own transaction
Capture one bounded res_pjsip exchange and preserve the SUBSCRIBE Request-URI, identified endpoint, Event and Accept headers, response and dialog identifiers. Confirm the endpoint's loaded allow_subscribe setting and context, plus the required event and body-generator modules. A matching hint in another context does not satisfy the request.
A rejected request follows its exact response: endpoint identification or authorization, missing hint/context, unsupported event package or unacceptable body format. Do not interpret a 200 response as a working lamp; it establishes only that this subscription transaction was accepted.
Correlate state changes with NOTIFY
After an accepted subscription, trigger one authorized state transition and correlate its timestamp with Asterisk's provider and extension state plus every NOTIFY sent in that dialog. Preserve the subscription state, content type, target identity, version sequence and response from the phone. Retransmission, expiry and resubscription are separate from the represented extension state.
If Asterisk state changes but no NOTIFY is emitted, investigate watcher ownership, module state and dialog lifetime. If a NOTIFY is sent but rejected, follow the response and negotiated body support. If it is accepted and contains the expected state, move to the phone's key mapping, parsing, provisioning and display rather than changing Asterisk state logic.
Separate device state from user presence and routing
Confirm what the key is meant to show. Device or dialog state can drive a busy lamp; presence state represents a user's selected availability and does not automatically change device availability or queue routing. A composite hint can also remain busy because another mapped device is in use.
Do not use a repaired lamp as proof of registration, contact qualification, call waiting, do-not-disturb, queue eligibility or successful dialing. Verify those controls with their own evidence. Likewise, do not set a Custom: or CustomPresence: value manually merely to force the desired colour unless an application explicitly owns and restores that state.
Check the narrow 22.11.0 regression signatures
If the running build is Asterisk 22.11.0, compare the incident with the 22.12.0-rc2 change record before rewriting hints. One reported regression withheld the initial NOTIFY when a dialog subscription's hint referenced CustomPresence and no AstDB entry existed; another removed caller identity from dialog-info+xml for a ringing extension. The first is not a general later-update failure, and the second is not a missing state transition when the body otherwise carries the expected ringing state.
Preserve the exact initial NOTIFY or ringing NOTIFY body and confirm the installed build. On October 8, 2026 the corrections were published in 22.12.0-rc2, a release candidate rather than a final maintenance release. Use the supported final package or managed-platform path when available; do not present candidate publication as production compatibility, availability or a tested repair.
Correct one boundary and retest expiry
Repair only the demonstrated owner: provider name or state writer, loaded hint/context, endpoint subscription permission, missing module, event/body compatibility, expired dialog or phone key configuration. Preserve the old setting and use the supported configuration owner before reload or restart.
Repeat idle, ringing, in-use and idle, then allow the subscription to refresh across its normal expiry. Confirm another watcher or target as a control and remove temporary SIP logging. No Asterisk host, dialplan, module, endpoint, subscription, NOTIFY body, phone, BLF key, queue, presence choice, compatibility, availability, price or live call was inspected or tested for this guide.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Asterisk device-state concepts ↗
- Asterisk extension state and hints ↗
- Asterisk state query and manipulation ↗
- Asterisk res_pjsip presence subscriptions ↗
- Asterisk presence-state concepts ↗
- Asterisk Development Team: 22.12.0-rc2 change record ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.