idnits 2.17.1 draft-hautakorpi-reason-header-for-warnings-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 331. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 308. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 315. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 321. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (October 12, 2005) is 6771 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) -- Looks like a reference, but probably isn't: 'RFC XXXX' on line 254 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group J. Hautakorpi, Ed. 3 Internet-Draft G. Camarillo 4 Expires: April 15, 2006 Ericsson 5 October 12, 2005 7 Extending the Session Initiation Protocol Reason Header with Warning 8 Codes 9 draft-hautakorpi-reason-header-for-warnings-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 15, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document specifies a new protocol value, called 'SIP-Warning', 43 for the Session Initiation Protocol (SIP) Reason header. The values 44 for the name space of 'SIP-Warning' are taken from the Warning codes 45 (warn-codes) of SIP. In addition, this document also defines one new 46 SIP Warning code to be used in situations where User Agent Server 47 (UAS) does not accept calls from an anonymous source. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 4. Example Use Cases . . . . . . . . . . . . . . . . . . . . . . . 4 55 5. New Warning Code for SIP . . . . . . . . . . . . . . . . . . . 6 56 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 57 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 58 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 60 8.2. Informational References . . . . . . . . . . . . . . . . . 7 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 62 Intellectual Property and Copyright Statements . . . . . . . . . . 9 64 1. Introduction 66 The main purpose of this document is to introduce a new protocol 67 value for Session Initiation Protocol (SIP) [3] Reason header field 68 [2]. The Reason header field provides information on why a SIP 69 request was issued. 71 The protocol value defined in this draft is called 'SIP-Warning' and 72 it consists of the Warning codes (warn-codes) defined in the Section 73 20.43 of [3]. With 'SIP-Warning', it is possible to convey richer 74 information about the reason why a SIP request was generated. 76 This draft defines also one new Warning code for the situations where 77 the User Agent Server (UAS) does not accept calls from an anonymous 78 source. 80 2. Terminology 82 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 83 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 84 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 85 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 86 compliant implementations. 88 3. Usage 90 A SIP entity MAY add a Reason header field with the 'SIP-Warning' 91 protocol value to a SIP request. Example syntax is as follows: 93 Reason: SIP-Warning; cause=304; text="Media type not available" 95 Currently, the Reason header field can convey the status code of the 96 response that triggered the generation of the SIP request in 97 question. By utilizing the possibility to convey more than one 98 Reason header field in one request, and by defining a new 'SIP- 99 Warning' protocol value, it is possible to also convey the 100 information contained in the Warning header field of the triggering 101 response to the final recipient. 103 The use of 'SIP-Warning' is especially useful in the context of SIP 104 Request History Information [4]. This is because SIP Request History 105 Information uses Reason entries to inform about which kind of 106 responses user agents return. 108 4. Example Use Cases 110 This section contains two example use cases of the 'SIP-Warning' 111 protocol value. The first example contains two user agent and one 112 third party call controller in the following example use case. A 113 simplified message exchange is illustrated in Figure 1. 115 A Controller B 116 | 1 INVITE | | 117 |<-------------------| | 118 | | | 119 | 2 200 OK | | 120 |------------------->| | 121 | | | 122 | 3 ACK | | 123 |<-------------------| | 124 | | | 125 | | 4 INVITE | 126 | |------------------------------>| 127 | | | 128 | | 5 480 Temporatily unavailable | 129 | |<------------------------------| 130 | | Warning: 399 pc2.example.org "Low battery" 131 | | | 132 | | 6 ACK | 133 | |------------------------------>| 134 | 7 BYE | | 135 |<-------------------| | 136 | Reason: SIP; cause=487; text="Request Terminated" | 137 | Reason: SIP-Warning; cause=399; text="Low battery" | 138 | | | 139 | 8 200 OK | | 140 |------------------->| | 141 | | | 143 Figure 1: Example Use Case with Third Party Call Controller 145 The third party call controller tries to establish a session between 146 A and B. However, B has a terminal with a battery, which is running 147 out. So, B do not want to take this call because it would drain out 148 the battery completely. If there would not be a way to convey 149 Warning codes in Reason header field, A would not have any way of 150 knowing why the session establishment really failed. 152 In the second use case user A tries to establish a sessions with B. 153 User B has registered three user agents, which are B1, B2 and B3. A 154 simplified message exchange is illustrated in Figure 2. When A send 155 an INVITE, the proxy sends INVITEs in sequence to B's registered user 156 agents. 158 A1 Proxy B1 B2 B3 159 | 1 INVITE | | | | 160 |--------->| 2 INVITE | | | 161 | |------------->| | | 162 | | | | | 163 | | 3 488 Not Acceptable Here | | 164 | |<-------------| | | 165 | | Warning: 305 pc1.example.org "Incomp. media" 166 | | | | | 167 | | 4 ACK | | | 168 | |------------->| | | 169 | | | | | 170 | | 5 INVITE | | | 171 | |---------------------------->| | 172 | | H-I: ;idx=1 | 174 | | | | | 175 | | 6 488 Not Acceptable Here | | 176 | |<----------------------------| | 177 | | Warning: 370 pc2.example.org "Insuf. bandwidth" 178 | | | | | 179 | | 7 ACK | | | 180 | |---------------------------->| | 181 | | | | | 182 | | 8 INVITE | | | 183 | |------------------------------------------->| 184 | | H-I: ;idx=1, | 186 | | ;idx=2 | 188 | | | | | 189 | | 9 200 OK | | | 190 | |<-------------------------------------------| 191 | | | | | 192 | | 10 ACK | | | 193 | |------------------------------------------->| 194 | | | | | 196 Figure 2: Example Use Case with a SIP Proxy 198 INVITEs to B1 and B2 fail, and their warning codes are conveyed in 199 responses 3 and 6. Proxy attaches the returned warning codes to 200 History-Info header field (denoted as 'H-I' on the figure). So, when 201 the B3 gets an INVITE, it can see why the previous INVITEs have 202 failed. 204 5. New Warning Code for SIP 206 The following SIP Warning code (warn-code) conveys information about 207 the event, where UAS has not accepted a call because it was 208 originated from an anonymous source. 210 390 Anonymous calls not allowed: UAS does not accept anonymous 211 calls. 213 The motivation behind the definition of this new Warning code is that 214 there are cases where there is a need to take automated actions based 215 on the fact the UAS has not accepted a call from anonymous source. 216 An example from such case is a situation where an anonymous call from 217 Public Switched Telephone Network (PSTN) is going to an IP network, 218 and then the UAS does not accept it. In this case, the gateway on 219 the communication path may need to take automated actions based on 220 the fact that callee does not accept anonymous calls. 222 Open issue: SIP's RFC [3] allows only such Warning codes that are 223 related to the Session Description Protocol (SDP). Should this be 224 the case also in the future? 226 6. Security Considerations 228 An attacker may attempt to add, modify, or remove the values that 229 belong to 'SIP-Warning' name space on Reason header field. This 230 could result in an application behaving in a non-desirable way. So, 231 it is strongly RECOMMENDED that integrity protection be applied to 232 the SIP messages in question. Eavesdropping does not pose any 233 threats or vulnerabilities, and it does not prevent a proper 234 operation. 236 A new Warning code, specified in Section 5 does not have any security 237 considerations in itself. 239 7. IANA Considerations 241 This document has two separate IANA considerations. The first one is 242 that this defines a new protocol value for the SIP Reason header 243 field: 245 Protocol value Protocol Cause Reference 246 -------------- ------------------------------ --------- 247 SIP-Warning Warning code [RFC XXXX] 249 The second IANA consideration is that a new Warning code for SIP 250 Warning code (warn-code) Registry is defined: 252 Code Description Reference 253 ---- ------------------------------------------------- --------- 254 390 Anonymous calls not allowed: UAS does not accept [RFC XXXX] 255 anonymous calls. 257 The 'RFC XXXX' tag needs to be replaced with the RFC number of this 258 document. 260 8. References 262 8.1. Normative References 264 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 265 Levels", BCP 14, RFC 2119, March 1997. 267 [2] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header 268 Field for the Session Initiation Protocol (SIP)", RFC 3326, 269 December 2002. 271 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 272 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 273 Session Initiation Protocol", RFC 3261, June 2002. 275 8.2. Informational References 277 [4] Barnes, M., "An Extension to the Session Initiation Protocol for 278 Request History Information", draft-ietf-sip-history-info-06 279 (work in progress), January 2005. 281 Authors' Addresses 283 Jani Hautakorpi (editor) 284 Ericsson 285 Hirsalantie 11 286 Jorvas 02420 287 Finland 289 Email: Jani.Hautakorpi@ericsson.com 291 Gonzalo Camarillo 292 Ericsson 293 Hirsalantie 11 294 Jorvas 02420 295 Finland 297 Email: Gonzalo.Camarillo@ericsson.com 299 Intellectual Property Statement 301 The IETF takes no position regarding the validity or scope of any 302 Intellectual Property Rights or other rights that might be claimed to 303 pertain to the implementation or use of the technology described in 304 this document or the extent to which any license under such rights 305 might or might not be available; nor does it represent that it has 306 made any independent effort to identify any such rights. Information 307 on the procedures with respect to rights in RFC documents can be 308 found in BCP 78 and BCP 79. 310 Copies of IPR disclosures made to the IETF Secretariat and any 311 assurances of licenses to be made available, or the result of an 312 attempt made to obtain a general license or permission for the use of 313 such proprietary rights by implementers or users of this 314 specification can be obtained from the IETF on-line IPR repository at 315 http://www.ietf.org/ipr. 317 The IETF invites any interested party to bring to its attention any 318 copyrights, patents or patent applications, or other proprietary 319 rights that may cover technology that may be required to implement 320 this standard. Please address the information to the IETF at 321 ietf-ipr@ietf.org. 323 Disclaimer of Validity 325 This document and the information contained herein are provided on an 326 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 327 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 328 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 329 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 330 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 331 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 333 Copyright Statement 335 Copyright (C) The Internet Society (2005). This document is subject 336 to the rights, licenses and restrictions contained in BCP 78, and 337 except as set forth therein, the authors retain all their rights. 339 Acknowledgment 341 Funding for the RFC Editor function is currently provided by the 342 Internet Society.