Read 489 as an event-package rejection
RFC 6665 defines 489 Bad Event when the responding server does not understand the event package named by the Event header. Preserve the exact SUBSCRIBE Request-URI, Call-ID, CSeq, Event token and parameters, response source and timestamp. A phone display that says presence or BLF does not establish the token actually sent or the server that rejected it.
The Event header carries exactly one registered package name for a SUBSCRIBE. Do not treat 489 as a generic call, registration or media error, and do not change RTP, codecs or NAT merely because the status is in the 4xx class.
Distinguish package support from format support
A notifier that understands the event package but cannot generate a NOTIFY body format permitted by the request's Accept header uses 406 under RFC 6665. Therefore capture Event and every Accept value together: changing a MIME type cannot install an event handler, while changing the Event token cannot make the subscriber interpret a body it does not support.
A missing Event header normally also leads to 489 when the notifier does not implement the legacy PINT exception. Keep malformed syntax, unsupported package name, unsupported parameter and unacceptable response-body format as separate observations.
Use Allow-Events as a capability hint
RFC 6665 says an Allow-Events header, when present, lists packages for which that user agent can act as a notifier. It can guide investigation, but its absence does not prove lack of support and its presence does not prove that the target resource exists, the subscriber is authorized or the feature works end to end. Proxies must not insert the header.
Probe only an authorized known resource and preserve the actual response. Do not convert an advertised package into a deployment-wide compatibility claim.
Correct the package owner and prove the full subscription
If the subscriber sent the wrong Event token, correct the phone, application or provisioning template that owns it. If the intended notifier lacks the package handler, confirm that the feature and module are supported for the deployed release before enabling anything. Do not substitute another package merely to suppress the status; presence, dialog and message-summary describe different state.
After the narrow correction, repeat the initial SUBSCRIBE and follow the resulting NOTIFY transaction, Content-Type, Subscription-State, expiry and application indication. A 200 response alone does not prove that later state delivery is correct. Use the Asterisk PJSIP 489 investigation for the server-side evidence path.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- IETF RFC 6665: event identification and notifier behavior ↗
- IETF RFC 6665: 489 Bad Event ↗
- IANA SIP event-type registry ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.