Bind 489 to the SUBSCRIBE and Asterisk leg
Record the timestamp and timezone, subscriber, target identity, PJSIP endpoint or trunk, Request-URI, Call-ID, CSeq, exact Event value and parameters, all Accept values and the source of the 489. Determine whether Asterisk sent the response to an inbound SUBSCRIBE or received it from another notifier on an outbound leg. Asterisk can terminate one subscription relationship and originate another, so fields remain leg-specific.
With authorization, use pjsip set logger on only for a bounded reproduction, then disable it and protect identities, credentials, presence state and message bodies. Do not assign the rejection to Asterisk, the phone or an upstream service from a display label alone.
Confirm the package rather than the feature label
Compare the wire Event token byte-for-byte with the package documented for the intended feature. A receptionist key described as BLF can use a dialog or presence subscription; voicemail indication normally uses message-summary. Those packages are not interchangeable, and a provisioning template can send a vendor-specific or misspelled token even when its user-interface label looks correct.
Preserve any Event parameters, including an id parameter, and the target URI. RFC 6665 makes the package name part of subscription identity. Correct the setting at the phone, application or provisioning owner instead of adding a server alias whose semantics are unknown.
Inspect the loaded Asterisk handler chain
Asterisk documents res_pjsip_pubsub.so as the core for subscriptions. Its PJSIP troubleshooting guide separately names res_pjsip_exten_state.so for presence or dialog handling and res_pjsip_mwi.so plus res_pjsip_mwi_body_generator.so for message-summary. Check the modules and subscription state supported by the deployed release; a module listed in documentation is not proof that it is installed, loaded or allowed for this endpoint.
Keep the package handler separate from the NOTIFY body generator. If Asterisk recognizes the Event value but lacks a mutually acceptable body format, investigate 406 and Accept rather than relabeling the problem as 489. In FreePBX, retain its module and generated-configuration ownership.
Keep resource, authorization and dialog failures separate
Package recognition is only one gate. After it passes, the notifier can still reject an unknown target, forbidden subscription, unacceptable expiry or request within unusable dialog state. Preserve the next response rather than assuming that disappearance of 489 proves that the watched extension, mailbox or policy is correct.
An Allow-Events value can support the package hypothesis, but it does not establish endpoint authorization or resource existence. Likewise, an Asterisk CLI warning about a missing hint belongs to the target-resource path after the package handler is selected; it is not evidence that every 489 is a missing hint.
Retest establishment, notification and refresh
Change only the demonstrated provisioning token, supported module state or feature owner, with a rollback path. Repeat the initial SUBSCRIBE, confirm the intended responder accepts it, and inspect the associated NOTIFY Event, Content-Type, Subscription-State and body. Then verify refresh, reconnect and termination behavior plus the actual phone or application indication.
Retain a negative test for an unsupported package when policy permits. No PBX, endpoint, subscription, package handler, body generator, resource, authorization rule, notification, presence indication, voicemail lamp or live transaction was tested for this guide.
module show like res_pjsip_pubsub.so
module show like res_pjsip_exten_state.so
module show like res_pjsip_mwi.so
pjsip set logger on
# Reproduce one authorized subscription, then disable temporary logging.Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- IETF RFC 6665: SIP event notification and 489 ↗
- Asterisk PJSIP troubleshooting guide: subscriptions ↗
- Asterisk res_pjsip_pubsub module reference ↗
- Asterisk presence-subscription configuration ↗
- Asterisk collecting debug information ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.