idnits 2.17.1 draft-camarillo-sipping-reason-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2002) is 8077 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '4' is mentioned on line 110, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Gonzalo Camarillo 3 Internet draft Ericsson 4 5 March 2002 6 Expires: September 2002 8 Session Initiation Protocol: Requirements on Reason Information beyond 9 the Status Code 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. Internet-Drafts are draft documents valid for a maximum of 20 six months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- Drafts 22 as reference material or to cite them other than as "work in 23 progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 Some applications need to know why a particular SIP message was 33 issued. This document describes those applications and provides a 34 set of requirements that a mechanism used to transport this type of 35 information has to fulfill. 37 Camarillo 1 38 SIP: Requirements on Reason Information 40 1. Introduction 42 SIP [1] responses contain a status code and a reason phrase. The 43 status code is intended to be parsed by a SIP entity whereas the 44 reason phrase is intended for a human. Both contain the reason why a 45 SIP response was generated. However, SIP does not provide a way to 46 express why a request was sent. 48 Although SIP responses carry a status code, in some situations a 49 response needs to carry additional information about why that status 50 code was generated. 52 The following sections describe applications that need this 53 information in order to function properly or to provide services. 54 Section 4 contains requirements that are essential for a SIP 55 implementation to work properly in a forking environment. Section 5 56 contains requirements that, if they are fulfilled, will enable the 57 creation of different services. Section 6 contains requirements that 58 will help debugging SIP networks. 60 2. Scope 62 This document describes applications that need to know why a SIP 63 message was generated. This is different from knowing why a SIP 64 client chose to send a SIP message to a particular SIP server. The 65 latter is outside the scope of this draft. 67 3. Terminology 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 71 this document are to be interpreted as described in RFC 2119 [2] and 72 indicate requirement levels for compliant mechanisms. 74 4. Forking environment 76 The Heterogeneous Error Response Forking Problem (HERFP) appears 77 when a proxy server forks a request to several destinations and one 78 (or more) of them returns a repairable error response. Repairable 79 error responses are those which request more information from the 80 user agent client in order to proceed. They can request, for 81 instance, authentication credentials or a different format or 82 enconding of the message body. 84 Since a forking proxy can only return one non-2xx final response, 85 these repairable responses are encapsulated in provisional 155 86 responses [3]. The status code is changed to 155 and the remaining 87 of the response is left as it was. Therefore, the non-2xx final 88 status code is lost. 90 A mechanism MUST be available for a UAS to include in a 155 91 response the status code of the non-2xx final response that 92 triggered it. 94 Camarillo 2 95 SIP: Requirements on Reason Information 97 It is a matter of local policy to use the reason phrase of the non- 98 2xx final response in the 155 response or to use the default reason 99 phrase for 155 responses (Update Requested). The reason phrase of 100 the non-2xx final response is important, because the user may have 101 to provide extra information before issuing an UPDATE request (e.g., 102 introducing a password) based on it. The reason phrase may be also 103 useful for debugging purposes. 105 A mechanism MUST be available for a UAS to include in a 155 106 response the reason phrase of the non-2xx final that triggered 107 it. 109 The two requirements above are of special importance for the 110 transition from SDP to SDPng [4]. If a request forks and arrives to 111 different UASs, some of them may only support SDP while others only 112 support SDP. Being able to return the non-2xx final status code to 113 the UAC allows the UAC to provide each particular UAS with the 114 session description format it understands. 116 5. Service creation 118 Some applications need to know why a SIP dialog was terminated in 119 order to implement services for the user. These applications need to 120 know why a CANCEL or a BYE was generated. 122 A mechanism SHOULD be available for SIP clients to indicate 123 whether a dialog was terminated because another branch answered 124 or because the whole session establishment (or session) was 125 terminated. 127 Third party call control [5] is widely used for service invocation. 128 A third party call controller sometimes has to map a non-2xx final 129 response on one SIP dialog to a BYE on another SIP dialog. When two 130 UAs are communicating through a controller, it is useful to provide 131 information about which final response triggered the BYE request 132 (e.g., User Busy). 134 A mechanism SHOULD be available for UASs to indicate which non- 135 2xx status code and reason phrase triggered a BYE. 137 5. Debugging 139 Gateways interworking with different protocols typically generate 140 SIP messages upon reception of messages from another protocol. In 141 particular, B2BUAs (e.g., a third party call controller) generate 142 SIP messages upon reception of other SIP messages. 144 In order to perform debugging in a system with such entities is 145 useful to know what, at the other side of the interworking point, 146 triggered the termination of a particular SIP dialog. 148 Camarillo 3 149 SIP: Requirements on Reason Information 151 A mechanism SHOULD be available for UAs acting as gateways or 152 B2BUAs to indicate what triggered a particular BYE or CANCEL 153 request. The trigger MAY be a SIP message or a message from a 154 protocol different than SIP, which may carry the reason why it 155 was sent. 157 Once a session has been established, it can be terminated because 158 the user wants to or because there is a problem in the network that 159 makes it impossible to continue with the session. 161 A mechanism SHOULD be available for UAs to indicate whether a 162 BYE or a CANCEL is sent due to an interaction with the user or 163 the dialog is terminated due to a network problem (e.g., no 164 media has been received). 166 8. References 168 [1] J. Rosenberg, H. Schulzrinne, et al., "SIP: Session initiation 169 protocol," Internet Draft, Internet Engineering Task Force, Feb. 170 2002. Work in progress. 172 [2] S. Bradner, "Key words for use in RFCs to indicate requirement 173 levels," Request for Comments 2119, Internet Engineering Task Force, 174 Mar. 1997. 176 [3] J. Rosenberg, "The SIP UPDATE Method," Internet Draft, Internet 177 Engineering Task Force, Mar. 2002. Work in progress. 179 [4]J. Ott, C. Perkins, "SDPng Transition," Internet Draft, Internet 180 Engineering Task Force, Feb. 2002. Work in progress. 182 [5] J. Rosenberg, et al., "Third Party Call Control in SIP," 183 Internet Draft, Internet Engineering Task Force, Nov. 2001. Work in 184 progress. 186 9. Author's Address 188 Gonzalo Camarillo 189 Ericsson 190 Advanced Signalling Research Lab. 191 FIN-02420 Jorvas 192 Finland 194 Phone: +358 9 299 3371 195 Fax: +358 9 299 3118 196 Email: Gonzalo.Camarillo@ericsson.com 198 Camarillo 4 199 SIP: Requirements on Reason Information 201 Full Copyright Statement 203 Copyright (c) The Internet Society (2002). All Rights Reserved. 205 This document and translations of it may be copied and furnished to 206 others, and derivative works that comment on or otherwise explain it 207 or assist in its implementation may be prepared, copied, published 208 and distributed, in whole or in part, without restriction of any 209 kind, provided that the above copyright notice and this paragraph 210 are included on all such copies and derivative works. However, this 211 document itself may not be modified in any way, such as by removing 212 the copyright notice or references to the Internet Society or other 213 Internet organizations, except as needed for the purpose of 214 developing Internet standards in which case the procedures for 215 copyrights defined in the Internet Standards process must be 216 followed, or as required to translate it into languages other than 217 English. 219 The limited permissions granted above are perpetual and will not be 220 revoked by the Internet Society or its successors or assigns. 222 This document and the information contained herein is provided on an 223 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 224 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 225 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 226 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 227 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 229 Camarillo 5