RFC 3326 (rfc3326) - Page 2 of 8
The Reason Header Field for the Session Initiation Protocol (SIP)
Alternative Format: Original Text Document
RFC 3326 The Reason Header Field for SIP December 2002
Table of Contents
1. Introduction ............................................... 2
1.1. Terminology ................................................ 3
2. The Reason Request Header Field ............................ 3
3. Examples ................................................... 4
3.1. Call Completed Elsewhere ................................... 4
3.2. Refusing an Offer that Comes in a Response ................. 4
3.3. Third Party Call Control ................................... 5
3.4. ISUP interworking .......................................... 5
4. IANA Considerations ........................................ 6
5. Security Considerations .................................... 6
6. Acknowledgments ............................................ 7
7. Authors' Addresses ......................................... 7
8. Normative References ....................................... 7
9. Full Copyright Statement ................................... 8
1. Introduction
The same SIP [1] request can be issued for a variety of reasons. For
example, a SIP CANCEL request can be issued if the call has completed
on another branch or was abandoned before answer. While the protocol
and system behavior is the same in both cases, namely, alerting will
cease, the user interface may well differ. In the second case, the
call may be logged as a missed call, while this would not be
appropriate if the call was picked up elsewhere.
Third party call controllers sometimes generate a SIP request upon
reception of a SIP response from another dialog. Gateways generate
SIP requests after receiving messages from a different protocol than
SIP. In both cases the client may be interested in knowing what
triggered the SIP request.
SIP responses already offer a means of informing the user of why a
request failed. The simple mechanism in this document accomplishes
something roughly similar for requests.
An INVITE can sometimes be rejected not because the session
initiation was declined, but because some aspect of the request was
not acceptable. If the INVITE forked and resulted in a rejection,
the error response may never be forwarded to the client unless all
the other branches also reject the request. This problem is known as
the "Heterogeneous Error Response Forking Problem", or HERFP. It is
foreseen that a solution to this problem may involve encapsulating
the final error response in a provisional response. The Reason header
field is a candidate to be used for such encapsulation.
Schulzrinne, et. al. Standards Track