idnits 2.17.1 draft-schulzrinne-dispatch-status-unwanted-00.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 date (September 30, 2016) is 2758 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) == Unused Reference: 'RFC3261' is defined on line 143, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-stir-rfc4474bis-13 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DISPATCH H. Schulzrinne 3 Internet-Draft FCC 4 Intended status: Standards Track September 30, 2016 5 Expires: April 3, 2017 7 A SIP Response Code for Unwanted Calls 8 draft-schulzrinne-dispatch-status-unwanted-00 10 Abstract 12 This document defines the 666 (Unwanted) SIP response code, allowing 13 called parties to indicate that the call was unwanted. The 14 terminating SIP entity may use this information to adjust future call 15 handling behavior for this called party or more broadly. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on April 3, 2017. 34 Copyright Notice 36 Copyright (c) 2016 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Normative Language . . . . . . . . . . . . . . . . . . . . . 2 53 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 4. Behavior of SIP Entities . . . . . . . . . . . . . . . . . . 3 55 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 56 6. Security Considerations . . . . . . . . . . . . . . . . . . . 3 57 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 3 58 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 8.1. Normative References . . . . . . . . . . . . . . . . . . 3 60 8.2. Informative References . . . . . . . . . . . . . . . . . 4 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 63 1. Introduction 65 In many countries, an increasing number of calls are unwanted 66 [RFC5039], as they might be fraudulent, illegal telemarketing or the 67 receiving party does not want to be disturbed by, say, surveys or 68 solicitation by charities. Carriers and other service providers may 69 want to help their subscribers avoid receiving such calls, using a 70 variety of global or user-specific filtering algorithms. One input 71 into such algorithms is user feedback. User feedback may be offered 72 through smartphone apps, APIs or within the context of a SIP- 73 initiated call. This document addresses only the last mode, where 74 the called party either rejects the SIP INVITE request as unwanted or 75 terminates the call with a BYE request after answering the call. To 76 allow the called party to express that the call was unwanted, this 77 document defines the 666 (Unwanted) response code. 79 2. Normative Language 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in BCP 14, RFC 2119 84 [RFC2119]. 86 3. Motivation 88 None of the existing 4xx, 5xx or 6xx response codes allow the called 89 party to convey that they not only reject this call, e.g., using 480 90 (Temporarily Unavailable), 486 (Busy Here), 600 (Busy Everywhere), 91 603 (Decline) or 606 (Not Acceptable), but that the caller is 92 unwanted. The particular response code number was chosen to reflect 93 the distaste felt by many upon receiving such calls. 95 4. Behavior of SIP Entities 97 The SIP entities receiving this response code are not obligated to 98 take any particular action. The service provider delivering calls to 99 the user issuing the response MAY, for example, add the calling party 100 to a personal blacklist, or MAY use the information as input when 101 computing the likelihood that the calling party is placing unwanted 102 calls ("crowd sourcing"). 104 The response code MAY also be used in Reason header fields [RFC3326], 105 typically when the UAS issues a BYE request terminating an incoming 106 call. 108 5. IANA Considerations 110 This document register a new SIP response code. This response code 111 is defined by the following information, which is to be added to the 112 method and response-code sub-registry under 113 http://www.iana.org/assignments/sip-parameters. 115 Response Code Number 666 117 Default Reason Phrase Unwanted 119 Reference [this RFC] 121 6. Security Considerations 123 If the calling party number is spoofed, users may report the number 124 as placing unwanted calls, possibly leading to the blocking of calls 125 from the legitimate user of the number in addition to the unwanted 126 caller. Thus, it is RECOMMENDED that the response code is used for 127 creating call filters only if the calling party number has been 128 authenticated using [I-D.ietf-stir-rfc4474bis]. 130 7. Acknowledgements 132 TBD. 134 8. References 136 8.1. Normative References 138 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 139 Requirement Levels", BCP 14, RFC 2119, 140 DOI 10.17487/RFC2119, March 1997, 141 . 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 DOI 10.17487/RFC3261, June 2002, 147 . 149 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 150 Header Field for the Session Initiation Protocol (SIP)", 151 RFC 3326, DOI 10.17487/RFC3326, December 2002, 152 . 154 8.2. Informative References 156 [I-D.ietf-stir-rfc4474bis] 157 Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 158 "Authenticated Identity Management in the Session 159 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-13 160 (work in progress), September 2016. 162 [RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation 163 Protocol (SIP) and Spam", RFC 5039, DOI 10.17487/RFC5039, 164 January 2008, . 166 Author's Address 168 Henning Schulzrinne 169 FCC 170 450 12th Street SW 171 Washington, DC 20554 172 US 174 Email: henning.schulzrinne@fcc.gov