idnits 2.17.1 draft-schulzrinne-sip-reason-01.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 the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 6 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 133: '...her side. This reason code SHOULD only...' RFC 2119 keyword, line 144: '... The text phrase MAY be modified, e.g....' RFC 2119 keyword, line 160: '...s a Reason header field SHOULD copy it...' RFC 2119 keyword, line 165: '.... All new reason codes MUST be defined...' RFC 2119 keyword, line 169: '... values MUST refer to either an ITU-...' (1 more instance...) 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 (February 28, 2002) is 8086 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 section? '1' on line 209 looks like a reference -- Missing reference section? '2' on line 213 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force SIP WG 3 Internet Draft H. Schulzrinne 4 Columbia University 5 D. Oran 6 Cisco 7 G. Camarillo 8 Ericsson 9 draft-schulzrinne-sip-reason-01.txt 10 February 28, 2002 11 Expires: August 2002 13 The Reason Header Field for the Session Initiation Protocol 15 STATUS OF THIS MEMO 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress". 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 To view the list Internet-Draft Shadow Directories, see 34 http://www.ietf.org/shadow.html. 36 Abstract 38 For creating services, it is often useful to know why a SIP request 39 was issued. This document defines an optional informational header 40 field, Reason, that provides this information. 42 Table of Contents 44 1 Introduction ........................................ 3 45 1.1 Terminology ......................................... 3 46 2 The Reason Request Header Field ..................... 3 47 3 IANA Considerations ................................. 5 48 4 Security Considerations ............................. 5 49 5 Acknowledgments ..................................... 5 50 6 Authors' Addresses .................................. 5 51 7 Bibliography ........................................ 6 53 1 Introduction 55 The same SIP [1] request can be issued for a variety of reasons. For 56 example, a SIP CANCEL request can be issued if the call has completed 57 on another branch or was abandoned before answer. While the protocol 58 and system behavior is the same in both cases, namely, alerting will 59 cease, the user interface may well differ. In the second case, the 60 call may be logged as a missed call, while this would not be 61 appropriate if the call was picked up elsewhere. 63 Third party call controllers sometimes generate a SIP request upon 64 reception of a SIP response from another dialog. Gateways generate 65 SIP requests after receiving messages from a different protocol than 66 SIP. In both cases the client may be interested in knowing what 67 triggered the SIP request. 69 SIP responses already have a means of informing the user of why a 70 request failed. The simple mechanism in this draft accomplishes 71 something roughly similar for requests. 73 Initially, the request header field defined here appears to be most 74 useful for BYE and CANCEL requests, but it can appear in any requests 75 and in any response. 77 Clients and servers are free to ignore this header. It has no impact 78 on protocol processing. 80 1.1 Terminology 82 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 83 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 84 and "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and 85 indicate requirement levels for compliant SIP implementations. 87 2 The Reason Request Header Field 89 The Reason header field can appear in any request or response. The 90 syntax of the header field follows the standard SIP parameter syntax. 92 Reason = "Reason" HCOLON reason-code *(SEMI reason-params) 93 reason-code = 1*DIGIT 94 reason-params = triggered-by | protocol-cause | reason-text 95 | reason-extension 96 triggered-by = "triggered" EQUAL quoted-string 97 protocol-cause = "cause" EQUAL cause 98 cause = 1*DIGIT 99 reason-text = "text" EQUAL quoted-string 100 reason-extension = generic-param 102 Examples are: 104 Reason: 1 ;text="Call completed elsewhere" 105 Reason: 4 ;triggered="Q.850" ;cause=16 ;text="Terminated" 106 Reason: 7 ;triggered="SIP/2.0" ;cause=600 ;text="Busy Everywhere" 107 Reason: 8 ;triggered="SIP/2.0" ;cause=580 108 ;text="Precondition Failure" 110 The following reason codes and text phrases have been defined: 112 1. (Call completed elsewhere): CANCEL request; another branch 113 completed the call. 115 2. (Abandoned): CANCEL request; the call attempt was 116 abandoned. 118 3. (Timed out): CANCEL request; the call attempt timed out. 120 4. (Terminated): BYE request; the caller or callee terminated 121 the call. 123 5. (Transfer completed): BYE request; the call transfer was 124 completed. 126 6. (No media): BYE request; the call was terminated since the 127 other side did not receive media for an extended period of 128 time. 130 7. (Interworking): BYE and CANCEL requests and any final 131 response; the call was terminated because a gateway or a 132 third party call controller received an error or a release 133 message from the other side. This reason code SHOULD only 134 be used if none of the other reason codes is applicable. 136 8. (Offer refused): BYE and CANCEL request; an offer that the 137 client wanted to refuse was received in a response. The 138 user agent client terminates the session. 140 9. (Update requested): 155 response; the Reason header field 141 contains the status code of the final response that 142 triggered the 155 response. 144 The text phrase MAY be modified, e.g., translated into different 145 languages or enhanced with additional call-specific information, for 146 example, 148 Reason: 2 ;text="Anrufer gab nach 30 Sekunden auf" 150 The following values for the triggered parameter have been defined: 152 SIP/2.0: The cause parameter contains a SIP status code. 154 Q.850: The cause parameter contains an ITU-T Q.850 cause value 155 in decimal representation. 157 The default value is "SIP/2.0". 159 Proxies generating a CANCEL request upon reception of a CANCEL from 160 the previous hop that contains a Reason header field SHOULD copy it 161 into the new CANCEL request. 163 3 IANA Considerations 165 IANA registers new reason codes. All new reason codes MUST be defined 166 in an RFC. 168 IANA also registers new values for the triggered parameter. These 169 values MUST refer to either an ITU-T Recommendation number, an IETF 170 protocol name or the recognized protocol identifier from another 171 standardization organization. 173 4 Security Considerations 175 While spoofing or removing the Reason header field has no impact on 176 protocol operation, the user interface may change and end systems may 177 provide services based on this header field. Thus, it is RECOMMENDED 178 that this field is protected by a suitable integrity mechanism. 180 5 Acknowledgments 182 Jonathan Rosenberg provided helpful comments and suggestions. 184 6 Authors' Addresses 186 Henning Schulzrinne 187 Dept. of Computer Science 188 Columbia University 189 1214 Amsterdam Avenue 190 New York, NY 10027 191 USA 192 electronic mail: schulzrinne@cs.columbia.edu 194 David R. Oran 195 Cisco Systems, Inc. 196 Acton, MA 197 USA 198 electronic mail: oran@cisco.com 200 Gonzalo Camarillo 201 Ericsson 202 Advanced Signalling Research Lab. 203 FIN-02420 Jorvas 204 Finland 205 electronic mail: Gonzalo.Camarillo@ericsson.com 207 7 Bibliography 209 [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 210 session initiation protocol," Request for Comments 2543, Internet 211 Engineering Task Force, Mar. 1999. 213 [2] S. Bradner, "Key words for use in RFCs to indicate requirement 214 levels," Request for Comments 2119, Internet Engineering Task Force, 215 Mar. 1997. 217 Full Copyright Statement 219 Copyright (c) The Internet Society (2002). All Rights Reserved. 221 This document and translations of it may be copied and furnished to 222 others, and derivative works that comment on or otherwise explain it 223 or assist in its implementation may be prepared, copied, published 224 and distributed, in whole or in part, without restriction of any 225 kind, provided that the above copyright notice and this paragraph are 226 included on all such copies and derivative works. However, this 227 document itself may not be modified in any way, such as by removing 228 the copyright notice or references to the Internet Society or other 229 Internet organizations, except as needed for the purpose of 230 developing Internet standards in which case the procedures for 231 copyrights defined in the Internet Standards process must be 232 followed, or as required to translate it into languages other than 233 English. 235 The limited permissions granted above are perpetual and will not be 236 revoked by the Internet Society or its successors or assigns. 238 This document and the information contained herein is provided on an 239 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 240 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 241 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 242 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 243 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.