[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Internet Engineering Task Force                     Gonzalo Camarillo
Internet draft                                               Ericsson
March 2002
Expires: September 2002

 Session Initiation Protocol: Requirements on Reason Information beyond
                            the Status Code

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
      all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   Drafts. Internet-Drafts are draft documents valid for a maximum of
   six months and may be updated, replaced, or obsoleted by other
   documents at any time. It is inappropriate to use Internet- Drafts
   as reference material or to cite them other than as "work in

   The list of current Internet-Drafts can be accessed at
   The list of Internet-Draft Shadow Directories can be accessed at


   Some applications need to know why a particular SIP message was
   issued. This document describes those applications and provides a
   set of requirements that a mechanism used to transport this type of
   information has to fulfill.

Camarillo                                                            1

                SIP: Requirements on Reason Information

1. Introduction

   SIP [1] responses contain a status code and a reason phrase. The
   status code is intended to be parsed by a SIP entity whereas the
   reason phrase is intended for a human. Both contain the reason why a
   SIP response was generated. However, SIP does not provide a way to
   express why a request was sent.

   Although SIP responses carry a status code, in some situations a
   response needs to carry additional information about why that status
   code was generated.

   The following sections describe applications that need this
   information in order to function properly or to provide services.
   Section 4 contains requirements that are essential for a SIP
   implementation to work properly in a forking environment. Section 5
   contains requirements that, if they are fulfilled, will enable the
   creation of different services. Section 6 contains requirements that
   will help debugging SIP networks.

2. Scope

   This document describes applications that need to know why a SIP
   message was generated. This is different from knowing why a SIP
   client chose to send a SIP message to a particular SIP server. The
   latter is outside the scope of this draft.

3. Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   this document are to be interpreted as described in RFC 2119 [2] and
   indicate requirement levels for compliant mechanisms.

4. Forking environment

   The Heterogeneous Error Response Forking Problem (HERFP) appears
   when a proxy server forks a request to several destinations and one
   (or more) of them returns a repairable error response. Repairable
   error responses are those which request more information from the
   user agent client in order to proceed. They can request, for
   instance, authentication credentials or a different format or
   enconding of the message body.

   Since a forking proxy can only return one non-2xx final response,
   these repairable responses are encapsulated in provisional 155
   responses [3]. The status code is changed to 155 and the remaining
   of the response is left as it was. Therefore, the non-2xx final
   status code is lost.

        A mechanism MUST be available for a UAS to include in a 155
        response the status code of the non-2xx final response that
        triggered it.

Camarillo                                                            2

                SIP: Requirements on Reason Information

   It is a matter of local policy to use the reason phrase of the non-
   2xx final response in the 155 response or to use the default reason
   phrase for 155 responses (Update Requested). The reason phrase of
   the non-2xx final response is important, because the user may have
   to provide extra information before issuing an UPDATE request (e.g.,
   introducing a password) based on it. The reason phrase may be also
   useful for debugging purposes.

        A mechanism MUST be available for a UAS to include in a 155
        response the reason phrase of the non-2xx final that triggered

   The two requirements above are of special importance for the
   transition from SDP to SDPng [4]. If a request forks and arrives to
   different UASs, some of them may only support SDP while others only
   support SDP. Being able to return the non-2xx final status code to
   the UAC allows the UAC to provide each particular UAS with the
   session description format it understands.

5. Service creation

   Some applications need to know why a SIP dialog was terminated in
   order to implement services for the user. These applications need to
   know why a CANCEL or a BYE was generated.

        A mechanism SHOULD be available for SIP clients to indicate
        whether a dialog was terminated because another branch answered
        or because the whole session establishment (or session) was

   Third party call control [5] is widely used for service invocation.
   A third party call controller sometimes has to map a non-2xx final
   response on one SIP dialog to a BYE on another SIP dialog. When two
   UAs are communicating through a controller, it is useful to provide
   information about which final response triggered the BYE request
   (e.g., User Busy).

        A mechanism SHOULD be available for UASs to indicate which non-
        2xx status code and reason phrase triggered a BYE.

5. Debugging

   Gateways interworking with different protocols typically generate
   SIP messages upon reception of messages from another protocol. In
   particular, B2BUAs (e.g., a third party call controller) generate
   SIP messages upon reception of other SIP messages.

   In order to perform debugging in a system with such entities is
   useful to know what, at the other side of the interworking point,
   triggered the termination of a particular SIP dialog.

Camarillo                                                            3

                SIP: Requirements on Reason Information

        A mechanism SHOULD be available for UAs acting as gateways or
        B2BUAs to indicate what triggered a particular BYE or CANCEL
        request. The trigger MAY be a SIP message or a message from a
        protocol different than SIP, which may carry the reason why it
        was sent.

   Once a session has been established, it can be terminated because
   the user wants to or because there is a problem in the network that
   makes it impossible to continue with the session.

        A mechanism SHOULD be available for UAs to indicate whether a
        BYE or a CANCEL is sent due to an interaction with the user or
        the dialog is terminated due to a network problem (e.g., no
        media has been received).

8. References

   [1] J. Rosenberg, H. Schulzrinne, et al., "SIP: Session initiation
   protocol," Internet Draft, Internet Engineering Task Force, Feb.
   2002.  Work in progress.

   [2] S. Bradner, "Key words for use in RFCs to indicate requirement
   levels," Request for Comments 2119, Internet Engineering Task Force,
   Mar. 1997.

   [3] J. Rosenberg, "The SIP UPDATE Method," Internet Draft, Internet
   Engineering Task Force, Mar. 2002.  Work in progress.

   [4]J. Ott, C. Perkins, "SDPng Transition," Internet Draft, Internet
   Engineering Task Force, Feb. 2002.  Work in progress.

   [5] J. Rosenberg, et al., "Third Party Call Control in SIP,"
   Internet Draft, Internet Engineering Task Force, Nov. 2001.  Work in

9. Author's Address

      Gonzalo Camarillo
      Advanced Signalling Research Lab.
      FIN-02420 Jorvas

      Phone: +358 9 299 3371
      Fax: +358 9 299 3118
      Email: Gonzalo.Camarillo@ericsson.com

Camarillo                                                            4

                SIP: Requirements on Reason Information

   Full Copyright Statement

   Copyright (c) The Internet Society (2002). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an

Camarillo                                                            5

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/