The Reason Header Field for the Session Initiation Protocol (SIP)
RFC 3326

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 01

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.