idnits 2.17.1 draft-ietf-sipcore-status-unwanted-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 == Line 218 has weird spacing: '... Name sip.6...' -- The document date (April 19, 2017) is 2562 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 SIPCORE H. Schulzrinne 3 Internet-Draft FCC 4 Intended status: Standards Track April 19, 2017 5 Expires: October 21, 2017 7 A SIP Response Code for Unwanted Calls 8 draft-ietf-sipcore-status-unwanted-05 10 Abstract 12 This document defines the 607 (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 October 21, 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 . . . . . . . . . . . . . . . . . . . . . . . . 8 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 feedback within the SIP 76 call. Here, the called party either rejects the SIP [RFC3261] 77 request as unwanted or terminates the session with a BYE request 78 after answering the call. INVITE and MESSAGE requests are most 79 likely to trigger such a response. 81 To allow the called party to express that the call was unwanted, this 82 document defines the 607 (Unwanted) response code. The user agent of 83 the called party, based on input from the called party or some UA- 84 internal logic, uses this to indicate that this call is unwanted and 85 that future attempts are likely to be similarly rejected. While 86 factors such as identity spoofing and call forwarding may make 87 authoritative identification of the calling party difficult or 88 impossible, the network can use such a rejection -- possibly combined 89 with a pattern of rejections by other callees and/or other 90 information -- as input to a heuristic algorithm for determining 91 future call treatment. The heuristic processing and possible 92 treatment of persistently unwanted calls are outside the scope of 93 this document. 95 As in [I-D.ietf-stir-rfc4474bis], we use the term "caller identity" 96 or "calling party identity" in this document to mean either a 97 canonical address-of-record (AoR) SIP URI employed to reach a user 98 (such as 'sip:alice@atlanta.example.com'), or a telephone number, 99 which commonly appears in either a tel URI [RFC3966] or as the user 100 portion of a SIP URI. 102 2. Normative Language 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in BCP 14, RFC 2119 107 [RFC2119]. 109 3. Motivation 111 None of the existing 4xx, 5xx or 6xx response codes signify that this 112 SIP request is unwanted by the called party. For example, 603 113 (Decline) might be used if the called party is currently at dinner or 114 in a meeting, but does not want to indicate any specific reason. As 115 described in Section 21.6.2 [RFC3261], a 603 response may include a 116 Retry-After header field to indicate a better time to attempt the 117 call. Thus, the call is rejected due to the called party's 118 (temporary) disposition. As described in Section 4, the called party 119 invokes the "unwanted call" user interface and 607 (Unwanted) 120 response indicating that it is instead the caller's identity that is 121 causing the call to be rejected. The particular response code number 122 was chosen to reflect the distaste felt by many upon receiving such 123 calls. 125 4. Behavior of SIP Entities 127 The response code 607 MAY be used in a failure response for an 128 INVITE, MESSAGE, SUBSCRIBE or other out-of-dialog SIP request to 129 indicate that the offered communication is unwanted. The response 130 code MAY also be used as the value of the "cause" parameter of a SIP 131 reason-value in a Reason header field [RFC3326], typically when the 132 called party user agent issues a BYE request terminating an incoming 133 call or a forking proxy issues a CANCEL request after receiving a 607 134 response from one of the branches. (Including a Reason header field 135 with the 607 status code allows the called party user agent that 136 receives a CANCEL request to make an informed choice whether and how 137 to include such calls in their missed-call list or whether to show an 138 appropriate indication to the user.) 140 The SIP entities receiving this response code are not obligated to 141 take any particular action beyond those appropriate for 6xx 142 responses. Following the default handling for 6xx responses in 143 [RFC5057], the 607 response destroys the transaction. The service 144 provider delivering calls or messages to the user issuing the 145 response MAY take a range of actions, for example, add the calling 146 party to a personal blacklist specific to the called party, use the 147 information as input when computing the likelihood that the calling 148 party is placing unwanted calls ("crowd sourcing"), initiate a 149 traceback request, or report the calling party identity to consumer 150 complaint databases operated by government authorities. 152 The user experience is envisioned to be somewhat similar to email 153 spam buttons where the detailed actions of the email provider remain 154 opaque to the user. 156 Call handling for unwanted calls is likely to involve a combination 157 of heuristics, analytics, and machine learning. These may use call 158 characteristics such as call duration and call volumes for a 159 particular caller, as well changes in those metrics over time, as 160 well as user feedback. Implementations will have to make appropriate 161 trade-offs between falsely labeling a caller as unwanted and 162 delivering unwanted calls. 164 Systems receiving 607 responses could decide to treat pre-call and 165 mid-call responses differently, given that the called party has had 166 access to call content for mid-call rejections. 168 Depending on the implementation, the response code does not 169 necessarily automatically block all calls from that caller identity. 170 The same user interface action might also trigger addition of the 171 caller identity to a local, on-device blacklist or graylist, e.g., 172 causing such calls to be flagged or alerted with a different ring 173 tone. 175 The actions described here do not depend on the nature of the SIP 176 URI, e.g., whether it describes a telephone number or not; however, 177 the same anonymous SIP URI [RFC3323] may be used by multiple callers 178 and thus such URIs are unlikely to be appropriate for URI-specific 179 call treatment. SIP entities tallying responses for particular 180 callers may need to consider canonicalzing SIP URIs, including 181 telephone numbers, as described in [I-D.ietf-stir-rfc4474bis]. The 182 calling party may be identified in different locations in the SIP 183 header, e.g., the From header field, P-Asserted-Identity or History- 184 Info, and may also be affected by diverting services. 186 This document defines a SIP feature-capability [RFC6809], sip.607, 187 that allows the registrar to indicate that the corresponding proxy 188 supports this particular response code. This allows the UA, for 189 example, to provide a suitable user interface element, such as a 190 "spam" button, only if its service provider actually supports the 191 feature. The presence of the feature capability does not imply that 192 the provider will take any particular action, such as blocking future 193 calls. A UA may still decide to render a "spam" button even without 194 such a capability if, for example, it maintains a device-local 195 blacklist or reports unwanted calls to a third party. 197 5. IANA Considerations 199 5.1. SIP Response Code 201 This document registers a new SIP response code. This response code 202 is defined by the following information, which is to be added to the 203 "Response Codes" sub-registry under http://www.iana.org/assignments/ 204 sip-parameters. 206 Response Code Number 607 208 Default Reason Phrase Unwanted 210 Reference [this RFC] 212 5.2. SIP Global Feature-Capability Indicator 214 This document defines the feature capability sip.607 in the "SIP 215 Feature-Capability Indicator Registration Tree" registry defined in 216 [RFC6809]. 218 Name sip.607 220 Description This feature-capability indicator, when included in a 221 Feature-Caps header field of a REGISTER response, indicates that 222 the server supports, and will process, the 607 (Unwanted) response 223 code. 225 Reference [this RFC] 227 6. Security Considerations 229 If the calling party address is spoofed, users may report the caller 230 identity as placing unwanted calls, possibly leading to the blocking 231 of calls from the legitimate user of the caller identity in addition 232 to the unwanted caller, i.e., creating a form of denial-of-service 233 attack. Thus, the response code SHOULD NOT be used for creating 234 global call filters unless the calling party identity has been 235 authenticated using [I-D.ietf-stir-rfc4474bis] as being assigned to 236 the caller placing the unwanted call. (The creation of call filters 237 local to a user agent is beyond the scope of this document.) 239 Even if the identity is not spoofed, a call or message recipient 240 might flag legitimate caller identities, e.g., to exact vengeance on 241 a person or business, or simply by mistake. To correct errors, any 242 additions to a personal list of blocked caller identities should be 243 observable and reversible by the party being protected by the 244 blacklist. For example, the list may be shown on a web page or the 245 subscriber may be notified by periodic email reminders. Any 246 additions to a global or carrier-wide list of unwanted callers needs 247 to consider that any user-initiated mechanism will suffer from an 248 unavoidable rate of false positives and tailor their algorithms 249 accordingly, e.g., by comparing the fraction of delivered calls for a 250 particular caller that are flagged as unwanted rather than just the 251 absolute number, and considering time-weighted filters that give more 252 credence to recent feedback. 254 Since caller identities are routinely re-assigned to new subscribers, 255 algorithms are advised to consider whether the caller identity has 256 been re-assigned to a new subscriber and possibly reset any related 257 rating. (In some countries, there are services that track which 258 telephone numbers have been disconnected before they are re-assigned 259 to a new subscriber.) 261 Some call services such as 3PCC [RFC3725] and call transfer [RFC3665] 262 increase the complexity of identifying who (if anyone) should be 263 impacted by the receipt of 607 within BYE. Such services might cause 264 the wrong party to be flagged or prevent flagging the desired party. 266 For both individually-authenticated and unauthenticated calls, 267 recipients of response code 607 may want to distinguish responses 268 sent before and after the call has been answered, ascertaining 269 whether either response timing suffers from a lower false-positive 270 rate. 272 7. Acknowledgements 274 Tolga Asveren, Ben Campbell, Peter Dawes, Martin Dolly, Keith Drage, 275 Vijay Gurbani, Christer Holmberg, Olle Johansson, Paul Kyzivat, Jean 276 Mahoney, Marianne Mohali, Adam Montville, Al Morton, Denis Ovsienko, 277 Brian Rosen, Brett Tate, Chris Wendt, Dale Worley and Peter Yee (Gen- 278 ART reviewer) provided helpful comments. 280 8. References 282 8.1. Normative References 284 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 285 Requirement Levels", BCP 14, RFC 2119, 286 DOI 10.17487/RFC2119, March 1997, 287 . 289 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 290 A., Peterson, J., Sparks, R., Handley, M., and E. 291 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 292 DOI 10.17487/RFC3261, June 2002, 293 . 295 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 296 Header Field for the Session Initiation Protocol (SIP)", 297 RFC 3326, DOI 10.17487/RFC3326, December 2002, 298 . 300 [RFC6809] Holmberg, C., Sedlacek, I., and H. Kaplan, "Mechanism to 301 Indicate Support of Features and Capabilities in the 302 Session Initiation Protocol (SIP)", RFC 6809, 303 DOI 10.17487/RFC6809, November 2012, 304 . 306 8.2. Informative References 308 [I-D.ietf-stir-rfc4474bis] 309 Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 310 "Authenticated Identity Management in the Session 311 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16 312 (work in progress), February 2017. 314 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 315 Initiation Protocol (SIP)", RFC 3323, 316 DOI 10.17487/RFC3323, November 2002, 317 . 319 [RFC3665] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and 320 K. Summers, "Session Initiation Protocol (SIP) Basic Call 321 Flow Examples", BCP 75, RFC 3665, DOI 10.17487/RFC3665, 322 December 2003, . 324 [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. 325 Camarillo, "Best Current Practices for Third Party Call 326 Control (3pcc) in the Session Initiation Protocol (SIP)", 327 BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004, 328 . 330 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 331 RFC 3966, DOI 10.17487/RFC3966, December 2004, 332 . 334 [RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation 335 Protocol (SIP) and Spam", RFC 5039, DOI 10.17487/RFC5039, 336 January 2008, . 338 [RFC5057] Sparks, R., "Multiple Dialog Usages in the Session 339 Initiation Protocol", RFC 5057, DOI 10.17487/RFC5057, 340 November 2007, . 342 Author's Address 344 Henning Schulzrinne 345 FCC 346 445 12th Street SW 347 Washington, DC 20554 348 US 350 Email: henning.schulzrinne@fcc.gov