Summary

  • RFC 3680 modeled an address-of-record's registration state independently of its contact set. An address with no registered contacts still had a defined init state.
  • Most registration notifications could be partial. A subscriber needed to apply them in version order and request a full refresh after detecting a gap; none of this established presence, device liveness, or successful call delivery.

The empty list was not an empty answer. In RFC 3680, an address-of-record (AoR) could have no registered contacts and still possess a defined state: init. That small modeling choice turned absence into something a subscriber could learn. The registration machine belonged to the AoR; separate machines belonged to individual contacts, and those contact machines existed only while the contacts were registered.

Published in March 2004, RFC 3680 added the SIP reg event package. An authorized subscriber sent SUBSCRIBE; the registrar or notifier returned registration information as application/reginfo+xml. The initial notification could describe full state. Later notifications commonly carried only changed contacts. reginfo marked each document full or partial and gave it a version, beginning at zero and increasing by one for documents sent within that subscription.

That distinction made the feature useful and fragile in the same breath. A delta is compact because it says what changed, not everything that remains true. The subscriber therefore had to keep a local table and merge updates in sequence. A version exactly one higher could be processed as the next change. A lower version was stale and discarded. If the version jumped ahead, RFC 3680 said the subscriber should refresh so the notifier would send full state. That recovery rule mattered because a missed notification could otherwise leave the local table plausible but wrong.

The AoR state machine made the edge case legible. When its first contact was registered, the AoR moved from init to active. It stayed active while at least one contact remained. When the last expired or was removed, the AoR moved to terminated and immediately returned to init; the final transition was deliberately invisible and must not be sent in a NOTIFY. The contact's own termination, by contrast, could be reported as a changed contact. A notification could thus report that a contact ended while the address itself returned to a stable no-contact state.

But “active” was a registration fact, not a human one. It did not say a person was available, that a device was powered on now, or that an INVITE would succeed. RFC 3856 defined a distinct SIP Presence package; registration could contribute raw information to a presence service, but the two state models were not interchangeable. Nor did a standards-track document prove that any operator implemented these transitions as written.

RFC 3680's contribution was a careful boundary: expose registration changes to authorized observers while preserving a state for the empty case and a resynchronization path for missed deltas. The useful operational question is not simply “is there a contact?” It is “which subscription version does this view represent, did any update go missing, and what does registration evidence actually establish?”

Sources