idnits 2.17.1 draft-ietf-sipcore-status-unwanted-03.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 == Line 210 has weird spacing: '... Name sip.6...' -- The document date (February 15, 2017) is 2621 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) ** Downref: Normative reference to an Informational RFC: RFC 5057 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPCORE H. Schulzrinne 3 Internet-Draft FCC 4 Intended status: Standards Track February 15, 2017 5 Expires: August 19, 2017 7 A SIP Response Code for Unwanted Calls 8 draft-ietf-sipcore-status-unwanted-03 10 Abstract 12 This document defines the 666 (Unwanted) SIP response code, allowing 13 called parties to indicate that the call or message was unwanted. 14 SIP entities may use this information to adjust how future calls from 15 this calling party are handled for the 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 August 19, 2017. 34 Copyright Notice 36 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . 3 53 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 4. Behavior of SIP Entities . . . . . . . . . . . . . . . . . . 3 55 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 56 5.1. SIP Response Code . . . . . . . . . . . . . . . . . . . . 5 57 5.2. SIP Global Feature-Capability Indicator . . . . . . . . . 5 58 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 59 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 60 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 62 8.2. Informative References . . . . . . . . . . . . . . . . . 7 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 65 1. Introduction 67 In many countries, an increasing number of calls are unwanted 68 [RFC5039]: they might be fraudulent, illegal telemarketing or the 69 receiving party does not want to be disturbed by, say, surveys or 70 solicitation by charities. Carriers and other service providers may 71 want to help their subscribers avoid receiving such calls, using a 72 variety of global or user-specific filtering algorithms. One input 73 into such algorithms is user feedback. User feedback may be offered 74 through smartphone apps, APIs or within the context of a SIP- 75 initiated call. This document addresses only the last mode, where 76 the called party either rejects the SIP [RFC3261] request, typically 77 requests using the INVITE or MESSAGE methods, as unwanted or 78 terminates the session with a BYE request after answering the call. 79 To allow the called party to express that the call was unwanted, this 80 document defines the 666 (Unwanted) response code. The called user 81 agent (UAS), based on input from the called party or some UA-internal 82 logic, uses this to indicate that this call is unwanted and that 83 future attempts are likely to be similarly rejected. While factors 84 such as identity spoofing and call forwarding may make authoritative 85 identification of the calling party difficult or impossible, the 86 network can use such a rejection -- possibly combined with a pattern 87 of rejections by other callees and/or other information -- as input 88 to a heuristic algorithm for determining future call treatment. The 89 heuristic processing and possible treatment of persistently unwanted 90 calls are outside the scope of this document. 92 As in [I-D.ietf-stir-rfc4474bis], we use the term "caller identity" 93 or "calling party identity" in this document to mean either a 94 canonical address-of-record (AoR) SIP URI employed to reach a user 95 (such as 'sip:alice@atlanta.example.com'), or a telephone number, 96 which commonly appears in either a tel URI [RFC3966] or as the user 97 portion of a SIP URI. 99 2. Normative Language 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in BCP 14, RFC 2119 104 [RFC2119]. 106 3. Motivation 108 None of the existing 4xx, 5xx or 6xx response codes signify that this 109 SIP request is unwanted by the called party. For example, 603 110 (Decline) might be used if the called party is currently at dinner or 111 in a meeting, but does not want to indicate any specific reason. As 112 described in Section 21.6.2 [RFC3261], a 603 response may include a 113 Retry-After header field to indicate a better time to attempt the 114 call. Thus, the call is rejected due to the called party's 115 (temporary) disposition. As described in Section 4, the called party 116 invokes the "unwanted call" user interface and 666 (Unwanted) 117 response indicating that it is instead the caller's identity that is 118 causing the call to be rejected. The particular response code number 119 was chosen to reflect the distaste felt by many upon receiving such 120 calls. 122 4. Behavior of SIP Entities 124 The response code 666 MAY be used in a failure response for an 125 INVITE, MESSAGE, SUBSCRIBE or other out-of-dialog SIP request to 126 indicate that the offered communication is unwanted. The response 127 code MAY also be used as the value of the "cause" parameter of a SIP 128 reason-value in a Reason header field [RFC3326], typically when the 129 UAS issues a BYE request terminating an incoming call or the UAC 130 issues a CANCEL request when forking a call. (Including a Reason 131 header field with the 666 status code allows the UAS that receive a 132 CANCEL request to make an informed choice whether and how to include 133 such calls in their missed-call list.) 135 The SIP entities receiving this response code are not obligated to 136 take any particular action beyond those appropriate for 6xx 137 responses. Following the default handling for 6xx responses in 138 [RFC5057], the 666 response destroys the transaction. The service 139 provider delivering calls or messages to the user issuing the 140 response, for example, MAY add the calling party to a personal 141 blacklist specific to the called party, MAY use the information as 142 input when computing the likelihood that the calling party is placing 143 unwanted calls ("crowd sourcing"), MAY initiate a traceback request, 144 and MAY report the calling party identity to government authorities. 146 This specification does not mandate any particular action by SIP 147 entities and leaves those to implementations. Call handling for 148 unwanted calls is likely to involve a combination of heuristics, 149 analytics, machine learning, based on user feedback, call 150 characteristics such as call duration and call volumes, as well 151 changes in such metrics. Implementations will have to make 152 appropriate trade-offs between falsely labeling a caller as unwanted 153 and delivering unwanted calls. The user experience is envisioned to 154 be somewhat similar to email spam buttons where the detailed actions 155 of the email provider remain opaque to the user. 157 Systems receiving 666 responses could decide to treat pre-call and 158 mid-call responses differently, given that the called party has had 159 access to call content for mid-call rejections. In other words, 160 depending on the implementation, the response code does not 161 necessarily automatically block all calls from that caller identity. 162 The same user interface action might also trigger addition of the 163 caller identity to a local, on-device blacklist or graylist, e.g., 164 causing such calls to be flagged or alerted with a different ring 165 tone. 167 The actions described here do not depend on the nature of the SIP 168 URI, e.g., whether it describes a telephone number or not; however, 169 the same anonymous SIP URI [RFC3323] may be used by multiple callers 170 and thus such URIs are unlikely to be appropriate for URI-specific 171 call treatment. SIP entities tallying responses for particular 172 callers may need to consider canonicalzing SIP URIs, including 173 telephone numbers, as described in [I-D.ietf-stir-rfc4474bis]. The 174 calling party may be identified in different locations in the SIP 175 header, e.g., the From header field, P-Asserted-Identity or History- 176 Info, and may also be affected by diverting services. 178 This document defines a SIP feature-capability [RFC6809], sip.666, 179 that allows the registrar to indicate that the corresponding proxy 180 supports this particular response code. This allows the UA, for 181 example, to provide a suitable user interface element, such as a 182 "spam" button, only if its service provider actually supports the 183 feature. The presence of the feature capability does not imply that 184 the provider will take any particular action, such as blocking future 185 calls. A UA may still decide to render a "spam" button even without 186 such as a capability if, for example, it maintains a device-local 187 blacklist or reports unwanted calls to a third party. 189 5. IANA Considerations 191 5.1. SIP Response Code 193 This document registers a new SIP response code. This response code 194 is defined by the following information, which is to be added to the 195 "Response Codes" sub-registry under http://www.iana.org/assignments/ 196 sip-parameters. 198 Response Code Number 666 200 Default Reason Phrase Unwanted 202 Reference [this RFC] 204 5.2. SIP Global Feature-Capability Indicator 206 This document defines the feature capability sip.666 in the "SIP 207 Feature-Capability Indicator Registration Tree" registry defined in 208 [RFC6809]. 210 Name sip.666 212 Description This feature-capability indicator when used in a 213 REGISTER response indicates that the server will process the 666 214 response code. This does not imply any specific action. 216 Reference [this RFC] 218 6. Security Considerations 220 If the calling party address is spoofed, users may report the caller 221 identity as placing unwanted calls, possibly leading to the blocking 222 of calls from the legitimate user of the caller identity in addition 223 to the unwanted caller, i.e., creating a form of denial-of-service 224 attack. Thus, the response code SHOULD NOT be used for creating 225 global call filters unless the calling party identity has been 226 authenticated using [I-D.ietf-stir-rfc4474bis] as being assigned to 227 the caller placing the unwanted call. (The creation of call filters 228 local to a user agent is beyond the scope of this document.) 230 Even if the identity is not spoofed, a call or message recipient 231 might flag legitimate caller identities, e.g., to extract vengeance 232 on a person or business, or simply by mistake. To correct errors, 233 any additions to a personal list of blocked caller identities should 234 be observable and reversible by the party being protected by the 235 blacklist. For example, the list may be shown on a web page or the 236 subscriber may be notified by periodic email reminders. Any 237 additions to a global or carrier-wide list of unwanted callers needs 238 to consider that any user-initiated mechanism will suffer from an 239 unavoidable rate of false positives and tailor their algorithms 240 accordingly, e.g., by comparing the fraction of delivered calls for a 241 particular caller that are flagged as unwanted rather than just the 242 absolute number, and considering time-weighted filters that give more 243 credence to recent feedback. 245 Since caller identities are routinely re-assigned to new subscribers, 246 algorithms are advised to consider whether the caller identity has 247 been re-assigned to a new subscriber and possibly reset any related 248 rating. 250 Some call services such as 3PCC [RFC3725] and call transfer increase 251 the complexity of identifying who (if anyone) should be impacted by 252 the receipt of 666 within BYE. Such services might causes the wrong 253 party to be flagged or prevent flagging the desired party. 255 For both individually-authenticated and unauthenticated calls, 256 recipients of response code 666 may want to distinguish responses 257 sent before and after the call has been answered, ascertaining 258 whether either response timing suffers from a lower false-positive 259 rate. 261 7. Acknowledgements 263 Tolga Asveren, Peter Dawes, Martin Dolly, Keith Drage, Vijay Gurbani, 264 Olle Johansson, Paul Kyzivat, Jean Mahoney, Marianne Mohali, Brian 265 Rosen, Brett Tate, Chris Wendt and Dale Worley provided helpful 266 comments. 268 8. References 270 8.1. Normative References 272 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 273 Requirement Levels", BCP 14, RFC 2119, 274 DOI 10.17487/RFC2119, March 1997, 275 . 277 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 278 A., Peterson, J., Sparks, R., Handley, M., and E. 279 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 280 DOI 10.17487/RFC3261, June 2002, 281 . 283 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 284 Header Field for the Session Initiation Protocol (SIP)", 285 RFC 3326, DOI 10.17487/RFC3326, December 2002, 286 . 288 [RFC5057] Sparks, R., "Multiple Dialog Usages in the Session 289 Initiation Protocol", RFC 5057, DOI 10.17487/RFC5057, 290 November 2007, . 292 [RFC6809] Holmberg, C., Sedlacek, I., and H. Kaplan, "Mechanism to 293 Indicate Support of Features and Capabilities in the 294 Session Initiation Protocol (SIP)", RFC 6809, 295 DOI 10.17487/RFC6809, November 2012, 296 . 298 8.2. Informative References 300 [I-D.ietf-stir-rfc4474bis] 301 Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 302 "Authenticated Identity Management in the Session 303 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16 304 (work in progress), February 2017. 306 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 307 Initiation Protocol (SIP)", RFC 3323, 308 DOI 10.17487/RFC3323, November 2002, 309 . 311 [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. 312 Camarillo, "Best Current Practices for Third Party Call 313 Control (3pcc) in the Session Initiation Protocol (SIP)", 314 BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004, 315 . 317 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 318 RFC 3966, DOI 10.17487/RFC3966, December 2004, 319 . 321 [RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation 322 Protocol (SIP) and Spam", RFC 5039, DOI 10.17487/RFC5039, 323 January 2008, . 325 Author's Address 326 Henning Schulzrinne 327 FCC 328 445 12th Street SW 329 Washington, DC 20554 330 US 332 Email: henning.schulzrinne@fcc.gov