Summary

  • In RFC 6665, Subscription-State: terminated means the subscription is no longer active. It is not a generic assertion that the monitored resource has ended or disappeared.
  • The reasons describe different futures: timeout permits a new subscription, deactivated can signal notifier migration, invariant says the state should not change, and only noresource expressly says the monitored resource state no longer exists.
  • A defensible record keeps subscription lifecycle, resource-state body, NOTIFY transaction, event-package interpretation and any human or automated action as separate, linked receipts.

The red tile has collapsed two state machines

The word “terminated” invites a grammatical mistake. It sounds as if it must modify the noun displayed next to it: call terminated, mailbox terminated, device terminated, account terminated. In the header defined by RFC 6665, the noun is the subscription. A subscriber receiving the value must consider that subscription terminated. The field is authoritative and useful, but its object is narrow.

The monitored resource has a different state machine, supplied by an event package. A presence package, message-summary package, call package or application-specific package decides what the body means, whether it carries full or partial state, and what a neutral state should be. The generic SIP events framework deliberately does not turn all of those resources into one universal model.

That division is architectural, not pedantic. A monitoring relationship can fail while the subject remains healthy. A resource can disappear while an old subscription still awaits its final notification. An interface that stores both situations as one terminal value loses the information needed to distinguish failure of observation from change in the observed thing.

Seven reasons point to several futures

RFC 6665 gives the termination reason operational force. deactivated tells the client to form a new subscription immediately; migration between notifier nodes is one principal use. probation postpones a retry. rejected reports a change in authorization policy and advises against another attempt. timeout says the subscription was not refreshed before expiry and permits immediate re-subscription. giveup says the notifier could not obtain authorization in time.

The two reasons most likely to be confused make the boundary clearest. noresource says the resource state being monitored no longer exists. invariant says that state is guaranteed not to change for the foreseeable future. Both advise against re-subscribing, yet one describes absence and the other persistence. A database column called ended=true cannot preserve both meanings.

The reason can also be missing or unknown. In that case the client may attempt to subscribe again, subject to retry-after. Absence of a reason does not license an observer to invent noresource; it creates an evidence gap. An expires parameter attached to terminated cannot fill it either. The RFC says that parameter has no semantics there and must be ignored.

A final notification need not contain a final resource value

Unsubscribing uses a SUBSCRIBE request with Expires: 0. A successful unsubscription triggers a final NOTIFY, but RFC 6665 warns that the request may or may not contain information about the resource state. The subscriber must be ready for either form.

This matters wherever software treats the last packet as a tombstone. If the body is absent, the system has learned that the relationship ended, not what the resource’s last value was. If a body is present, its content type, package rules, full-versus-partial semantics and version information still govern interpretation. The header cannot silently lend meaning to bytes that belong to another specification.

The response to NOTIFY has a similarly bounded meaning. Once the notification is acceptable to the subscriber, it should return 200. The transaction must not remain open while waiting for a user. That response is evidence that an automated SIP element processed the request acceptably. It is not a read receipt, an operator acknowledgement or proof that a downstream workflow completed.

Creation can arrive out of conversational order

The first NOTIFY confirms creation of a subscription. A 200-class response to SUBSCRIBE says the request was accepted and that a NOTIFY will be sent immediately, but the NOTIFY can arrive before the SUBSCRIBE transaction finishes because messages may be reordered, lost or forked. Until the first NOTIFY arrives, the resource is to be treated as being in the neutral state defined by the event package.

There are therefore at least three clocks. The transaction clock follows requests and responses. The subscription clock follows creation, refresh, expiry and termination. The resource clock follows state changes described by the package. A fourth clock appears in the observer that receives, parses and displays the notification. Sorting all four by capture time and calling the last record “truth” can reverse cause and effect.

A useful audit does not merely keep a screenshot. It records the local subscription key, Call-ID and tags, Event value, target, NOTIFY CSeq, exact state header, reason, retry interval, receipt time, authentication result and response. Separately, it records whether a body existed, its media type and digest, the package and parser version, whether the state was full or partial where defined, and the application value derived from it.

A usage can end while its dialog continues

RFC 6665 defines a subscription as application state associated with a dialog. Robert Sparks’s RFC 5057 explains why that association must not be mistaken for identity. Dialog usages have independent lifecycles while sharing dialog state. A transfer scenario can have an invite usage and a subscription usage in the same dialog; the subscription can terminate while the invite usage remains.

Later work tightened the control surface. RFC 7621 clarifies the use of GRUUs so requests can target the intended user-agent instance. RFC 7647, written by Sparks and Roach, addresses REFER-created subscriptions and problematic dialog reuse. Better endpoint targeting and cleaner dialog structure reduce ambiguity about which usage produced an event. They do not expand terminated into a statement about the resource.

This is another reason to avoid labels such as “session ended.” The subscription, dialog, dialog usage, call, notifier instance and package-defined resource are related objects, not synonyms. Each deserves its own identifier and successor state.

Roach authored a framework that preserves the boundary

RFC 6665, published in July 2012, is the Standards Track replacement for RFC 3265. Adam Roach is the sole named author of both. His current IETF profile describes participation since 1998, service as Applications and Real-Time Area Director from 2017 through 2020 and earlier chair roles in XCON, SIPCORE and NETVC. The profile currently lists 23 RFCs and no active roles as of 22 April 2026.

Those facts establish standards contribution, not control of any particular deployment. A product’s reason mapping, timer policy or operator label belongs to that product and its operators. Roach’s name supplies provenance for the framework; it cannot certify an implementation or a resource-state claim.

The evidence bundle should answer five different questions

For subscription identity: which dialog, event package, target and local key? For lifecycle: which state, reason, expiry rule and receiving time? For resource state: was there a body, what package interpreted it, and what digest and version were observed? For transport custody: which notifier, authentication result, transaction and response? For action: did the system retry, wait, migrate, alert or close a case, under whose rule?

This separation does not weaken automation. It lets automation be precise. A timeout can open a monitoring-gap incident without declaring the resource dead. A deactivated result can remain pending until a successor subscription produces its first NOTIFY. A noresource result can require application corroboration before an irreversible business action. A missing reason can be shown honestly as unknown.

The strongest counterargument is that operators need one compact state. They do. But the compact state should describe what the protocol proved: subscription ended, reason known or unknown, resource evidence present or absent. Red is useful when its legend is truthful.

Sources