SIP SUBSCRIBE and NOTIFY: presence, BLF and event state

A subscription is not a registration

REGISTER tells a location service where an address can currently be reached. SUBSCRIBE asks to receive changes for an event package. NOTIFY carries the resulting state information. A phone can register successfully while its busy-lamp field remains wrong because the separate event subscription failed. The Event header identifies the package, while Subscription-State describes whether a subscription is pending, active or terminated. Event-package definitions determine the body format and what the state means; a presence document and a dialog-state document are not interchangeable.

Inspect a stale indicator

Capture the initial SUBSCRIBE, its response, the associated NOTIFY and subsequent refreshes. Read expiry values and any termination reason. Check that the monitored identity belongs to the intended tenant and that the subscriber is authorized to observe it. A successful SUBSCRIBE response alone does not prove the phone received or understood the notification body. Follow the NOTIFY transaction too. If the phone displays yesterday's state, investigate refresh failure, a transport reconnect and whether an initial full state was delivered after reconnection.

Design for scale and privacy

Subscriptions multiply with monitored keys: a receptionist monitoring many extensions creates a different workload from a phone with one line key. Estimate both refresh traffic and change-driven notifications before rolling out large BLF templates. Avoid exposing presence or call state to arbitrary authenticated users. Limit the observed resources and event packages to the operator's actual role. During troubleshooting, record the package, target identity and state transitions; redact personal identifiers before sharing a trace. Use event state to explain indicators, not as proof of end-to-end media health.

Keep event, format and resource failures separate

RFC 6665 uses 489 Bad Event when the notifier does not understand the event package named by the Event header. A known event package with no NOTIFY body format acceptable to the subscriber is instead a 406 investigation. A known package can still fail because the target resource is unknown or the subscriber is not authorized, so preserve the exact Request-URI, Event token, Accept values and responder.

An Allow-Events header advertises packages for which that user agent can act as a notifier, but it is not an end-to-end feature or authorization test. Follow the SIP 489 reference and the Asterisk PJSIP investigation before changing phone templates or loading modules.

Separate event-package NOTIFY from manual vendor commands

The Asterisk PJSIP NOTIFY guide keeps RFC subscription state and dialog matching distinct from manually triggered, vendor-defined endpoint messages.

Do not promote an AMI presence event into NOTIFY proof

The AMI presence-state guide separates provider change, hint change, subscription delivery and endpoint rendering.

Do not promote extension state into subscription proof

The AMI extension-state guide separates PBX hint evidence from SUBSCRIBE acceptance, NOTIFY delivery and endpoint rendering.