Summary

  • RFC 3326 let a SIP request carry the protocol cause that triggered it, so identical CANCEL or BYE actions could lead to different service and user-interface consequences.
  • Reason was optional, ignorable and outside core SIP processing; its namespace, creating or copying hop, mapping rule and integrity evidence had to remain separate from the event it claimed to describe.

The missed-call record depended on an event no longer visible

A forking proxy could send one INVITE toward several registered devices. If one branch returned 200 OK, the proxy stopped the remaining branches with CANCEL. A user watching either losing device saw the same outcome as when the caller simply gave up before answer: ringing ceased. Yet a call log should not necessarily treat the cases alike. “Answered elsewhere” is not a missed call; abandonment may be.

The CANCEL method described the action. It did not explain the event that caused the proxy to issue it. RFC 3326 inserted a second layer by defining Reason. In the successful-branch case, the proxy could put a SIP cause of 200 and the phrase “Call completed elsewhere” into the CANCEL sent to the other branches. The receiving device could use that context to avoid a misleading missed-call alert.

This was a small header with a large conceptual job. It allowed causality to survive after the protocol state transition had erased the visible difference. It also resisted the temptation to create a new CANCEL method for every reason. The request remained CANCEL; services received a separate annotation about its trigger.

Reason was not limited to that example. It could appear in any request within a dialog, in any CANCEL, and in a response whose status code explicitly permitted it. A client that received an unacceptable offer in a successful response could ACK correctly, send BYE and carry a SIP 488 cause explaining the termination. A third-party call controller that learned one party was busy could terminate a different dialog with a BYE carrying 486. A gateway could translate an ISUP release into a Q.850 cause.

The common pattern was a causal handoff. An outcome observed in one branch, dialog or protocol caused an action somewhere else. The later message had to preserve enough context for a consumer to understand why it existed.

A useful reason was still not a control instruction

RFC 3326 drew a boundary that implementations often blur: clients and servers were free to ignore Reason, and the field had no effect on protocol processing. The CANCEL canceled whether the field was present, absent, understood or discarded. Reason could influence a user interface, service choice or diagnostic record, but it did not redefine the transaction state machine.

That distinction makes the field an evidence object rather than an execution receipt. A capture can prove that a message contained protocol=SIP and a numeric cause. It cannot by itself prove that another branch really answered, that the sender directly observed the event, that an intermediary copied it faithfully or that the recipient used it. A service action based on Reason needs its own receipt.

The syntax reinforced the separation. Every Reason value began with a protocol namespace, followed by parameters such as a numeric cause, quoted text and extensions. SIP causes drew their numbers from SIP status codes. Q.850 causes came from a different code system. The number 16 under Q.850 meant normal call clearing; it was not SIP status 16. Removing the namespace to make analytics convenient would destroy meaning.

The text parameter was also not the machine authority. It made the cause readable, but translations, vendor wording or mistakes could diverge from the registered numeric meaning. Durable records therefore need the namespace and cause as structured fields, with text preserved separately rather than treated as the canonical code.

RFC 3326 originally allowed more than one Reason value only when every value named a different protocol, such as one SIP and one Q.850 value. RFC 9366 updated that rule in 2023. Multiple values for the same registered protocol may appear only when that protocol defines what repetition means. Otherwise, one value per protocol remains the rule. The update matters because a parser cannot decide that repeated causes are a list merely from syntax; semantics belong to the registration.

Translation preserved context and introduced new uncertainty

Interworking made Reason especially valuable. RFC 3398 specified mappings between ISUP and SIP. A PSTN gateway receiving an ISUP release could generate a SIP CANCEL with the Q.850 cause it received. The SIP side no longer had to infer why the external call leg ended from the fact of cancellation alone.

Later work refined the envelope. RFC 6432 allowed SIP responses other than 100 Trying to carry a Q.850 cause in Reason. RFC 8606 added a location extension when the ISUP release location was available. That location describes a broad place in the ISUP network—such as a local, transit or remote network—not the physical position or identity of the caller or callee.

Each extension increased information while also lengthening the provenance chain. A Q.850 value in SIP may be a direct translation of a received ISUP message, a copied upstream value or a locally generated approximation. The final sender is not necessarily the original observer. To call the value evidence, an operator needs the external message, mapping version, gateway identity, copy history and integrity state.

RFC 7044's History-Info and RFC 5806's historical Diversion mechanism address related but different questions. They describe retargeting or diversion history. Reason describes why a particular request or allowed response was issued. A route history cannot be substituted for a release cause, and a release cause does not reconstruct the complete route.

Copying kept causality alive and also spread mistakes

When a proxy received a CANCEL containing Reason and generated another CANCEL for the next hop, RFC 3326 said it should copy the field. Without copying, the action would propagate while its cause vanished. With copying, the eventual endpoint could make the better interface decision.

But copying changes the claim's provenance. The proxy sending the final CANCEL may only be repeating something learned several hops earlier. If a middlebox edits the text, changes a mapping, appends another value or drops the field, a packet capture at the endpoint cannot recover the original observation. Every copy needs to retain the distinction between observed, translated and relayed.

The security section focused on the Heterogeneous Error Response Forking Problem. A final error on one fork might not otherwise reach the client while other branches remained active. Spoofing or removing Reason in that setting could prevent the client from correctly updating its earlier request and could make session establishment impossible. The document therefore recommended suitable integrity protection.

Integrity protection, when actually present and validated, answers a bounded question: whether the protected bytes changed between identified protection endpoints. It does not prove the real-world event, correct mapping or honest initial assertion. Conversely, lack of protection does not make the field useless; it lowers the confidence and changes the actions that should depend on it.

The historical achievement of RFC 3326 was not that networks learned why calls ended. Networks already held fragments of that knowledge. The achievement was to keep the reason as a separate, namespaced and transportable object after the action had become indistinguishable. Its lasting lesson is equally precise: preserving a cause is not the same as certifying a history.

Sources