idnits 2.17.1 draft-jesske-dispatch-update3326-reason-responses-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 11, 2011) is 4636 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DISPATCH R. Jesske 3 Internet-Draft L. Liess 4 Intended status: Standards Track Deutsche Telekom 5 Expires: February 12, 2012 August 11, 2011 7 Carrying Q.850 Codes in Reason Header Fields in SIP (Session Initiation 8 Protocol) Responses 9 draft-jesske-dispatch-update3326-reason-responses-05 11 Abstract 13 Although the use of the Reason header field in responses is 14 considered in general in RFC3326, its use is not specified for any 15 particular response code. Nonetheless, existing deployments have 16 been using Reason header fields in responses to carry Q.850 cause 17 codes for failure responses to INVITE requests that have been 18 gatewayed to PSTN systems. This document normatively describes the 19 use of the Reason header field in SIP responses to carry Q.850 cause 20 codes. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on February 12, 2012. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . . 3 71 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 3 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 73 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4 74 7. Normative References . . . . . . . . . . . . . . . . . . . . . 4 76 1. Overview 78 Although the use of the Reason header field in responses is 79 considered in general in RFC3326[RFC3326], its use is not specified 80 for any particular response code. Nonetheless, existing deployments 81 have been using Reason header fields in responses to carry Q.850 82 [Q.850] cause codes for failure responses to INVITE requests that 83 have been gatewayed to PSTN systems. This document normatively 84 describes the use of the Reason header field in SIP responses to 85 carry Q.850 [Q.850] cause codes. 87 2. Terminology 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119]. 93 This document uses terms from [RFC3261]. 95 3. Applicability 97 This document allows SIP responses to carry Reason header fields as 98 follows: 100 Any SIP Response message, with the exception of a 100 (Trying) MAY 101 contain a Reason header field with a Q.850 [Q.850] cause code. 103 The Reason header field is not needed in the the 100 (Trying) 104 responses since they are transmitted hop-by-hop, not end-to-end. SIP 105 responses with Reason header fields carrying values other than Q.850 106 [Q.850] cause code are outside of the scope of this document. 108 4. Security Considerations 110 This specification allows the presence of the Reason containing Q.850 111 [Q.850] cause codes in responses. The presence of the Reason header 112 field in a response does not affect the treatment of the response. 113 Nevertheless, there could be situations where a wrong Q.850 [Q.850] 114 cause code could, for example, cause an announcement system to play 115 the wrong information. To avoid such situations, it is RECOMMENDED 116 that this header field is protected by a suitable integrity 117 mechanism. The use of transport or network layer hop-by-hop security 118 mechanisms, such as TLS or IPSec with appropriate cipher suites, can 119 satisfy this requirement. 121 5. IANA Considerations 123 No IANA actions are required 125 6. Acknowledgments 127 Thanks to Gonzalo Camarillo and Mary Barnes for the detailed review 128 of this document. 130 Thanks to Paul Kyzivat, Mary Barnes, John Elwell, Keith Drage, Thomas 131 Belling who provided helpful comments, feedback and suggestions. 133 7. Normative References 135 [Q.850] "Usage of cause and location in the Digital Subscriber 136 Signalling System No. 1 and the Signalling System No. 7 137 ISDN User Part [ITU-T Recommendation Q.850]", 138 ITU Recommendation Q.850, April 1998. 140 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 141 Requirement Levels", BCP 14, RFC 2119, March 1997. 143 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 144 A., Peterson, J., Sparks, R., Handley, M., and E. 145 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 146 June 2002. 148 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 149 Header Field for the Session Initiation Protocol (SIP)", 150 RFC 3326, December 2002. 152 Authors' Addresses 154 Roland Jesske 155 Deutsche Telekom 156 Heinrich-Hertz-Strasse 3-7 157 Darmstadt, 64307 158 Germany 160 Phone: +4961515812766 161 EMail: r.jesske@telekom.de 162 Laura Liess 163 Deutsche Telekom 164 Heinrich-Hertz-Strasse 3-7 165 Darmstadt, 64307 166 Germany 168 Phone: +4961515812761 169 EMail: Laura.Liess@telekom.de