Internet Engineering Task Force Gonzalo Camarillo Internet draft Ericsson <draft-camarillo-sipping-reason-00.txt> 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 progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract 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", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 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 it. 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 terminated. 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 progress. 9. Author's Address Gonzalo Camarillo Ericsson Advanced Signalling Research Lab. FIN-02420 Jorvas Finland 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 English. 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 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Camarillo 5