Summary

  • RFC 3326 let a SIP request carry a reason for being sent, including a SIP status cause or a Q.850 cause from telephony interworking.
  • The header did not alter SIP processing. A CANCEL still canceled; Reason could tell the remaining fork why it was sent, such as another branch completing the call.

One branch answered; the others still had to stop

A proxy sends an INVITE down several branches. One destination answers with 200 OK. The proxy now has a practical problem: the other phones may still be ringing. It sends CANCEL to those branches. Their alerting stops because the SIP method is CANCEL—not because a header explains the event.

RFC 3326, published in December 2002, gave the proxy a way to add that explanation: Reason: SIP;cause=200;text="Call completed elsewhere". The receiving service could distinguish a call answered on another branch from one abandoned before answer. That distinction could matter to a missed-call log or user interface even though the immediate protocol action was the same.

This small separation is the standard’s central design choice. SIP already had status codes for responses. But the same request can be issued for different reasons, and a request does not ordinarily carry the response that motivated it. Reason attached cause to the request that acted on it. It was explanatory metadata, not a second command channel.

The cause had an owner

RFC 3326 defined protocol-qualified values. SIP means the cause parameter is a SIP status code. Q.850 means it is a decimal cause value from the ITU-T telephony signaling plan. A gateway could therefore preserve a PSTN release cause while expressing the event in a SIP message. The number alone was not enough; the protocol label told a reader which numbering system supplied it.

The text parameter was useful to people, but it was not the authority for processing. The cause belonged to the named protocol’s vocabulary, and the surrounding message still supplied the actual method, status and transaction context. Treating cause=200 as though it were a response, or treating a Q.850 value as a SIP status, would collapse two different control surfaces.

Nor did the field promise universal comprehension. RFC 3326 allowed implementations to ignore values they did not understand, and explicitly said Reason had no impact on protocol processing. The request continued to work according to SIP even if an endpoint discarded the explanation. That made the extension useful for services without making it a hidden prerequisite for basic call state.

A response hidden by forking

The specification also connected Reason to the Heterogeneous Error Response Forking Problem. A forked INVITE may receive different final failures on different branches. Because a proxy generally waits for branch outcomes before deciding what to send upstream, a useful final error can be obscured while another branch remains pending. RFC 3326 identified encapsulating a final status in a provisional response as a possible use for Reason.

The wording matters: it described a candidate mechanism, not proof that every fork exposed every error or that a deployed service solved the problem. The header offered a container for a cause; it did not define a universal policy for ranking failures or replace SIP response handling.

Evolution kept the boundary visible

RFC 8606 later added an ISUP location parameter for Q.850 causes, allowing signaling to preserve where a release originated when that information was available. RFC 9366 later relaxed the original one-value-per-protocol rule only for registered protocols that define the meaning of multiple values. In both cases, added structure made the provenance more precise; it did not make Reason the operation itself.

That is a useful historical distinction. RFC 3087 explored a Request-URI as a local service-selection context; RFC 3326 attached cause to an already chosen SIP action. One selected where a request went. The other explained why it had been issued. In neither case should a reader infer authentication, authorization, a complete call history or a successful downstream outcome from the string alone.

Sources

  1. https://www.rfc-editor.org/rfc/rfc3326.html
  2. https://www.rfc-editor.org/info/rfc3326/
  3. https://www.rfc-editor.org/rfc/rfc3261.html
  4. https://www.rfc-editor.org/rfc/rfc9366.html
  5. https://www.rfc-editor.org/rfc/rfc8606.html
  6. https://www.rfc-editor.org/rfc/rfc5411.html
  7. https://www.rfc-editor.org/rfc/rfc4411.html