The Reason Header Field for the Session Initiation Protocol (SIP)
RFC 3326
Document | Type |
RFC - Proposed Standard
(December 2002; No errata)
Updated by RFC 8606
Was draft-ietf-sip-reason (sip WG)
|
|
---|---|---|---|
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 3326 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Allison Mankin | ||
IESG note | Published. | ||
Send notices to | <rohan@cisco.com> |
Network Working Group H. Schulzrinne Request for Comments: 3326 Columbia University Category: Standards Track D. Oran Cisco G. Camarillo Ericsson December 2002 The Reason Header Field for the Session Initiation Protocol (SIP) Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract For creating services, it is often useful to know why a Session Initiation Protocol (SIP) request was issued. This document defines a header field, Reason, that provides this information. The Reason header field is also intended to be used to encapsulate a final status code in a provisional response. This functionality is needed to resolve the "Heterogeneous Error Response Forking Problem", or HERFP. Schulzrinne, et. al. Standards Track [Page 1] 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 [Page 2] RFC 3326 The Reason Header Field for SIP December 2002 Initially, the Reason header field defined here appears to be most useful for BYE and CANCEL requests, but it can appear in any request within a dialog, in any CANCEL request and in any response whose status code explicitly allows the presence of this header field. Note that the Reason header field is usually not needed in responses because the status code and the reason phrase already provide sufficient information. Clients and servers are free to ignore this header field. It has no impact on protocol processing.Show full document text