--- 1/draft-ietf-sipcore-status-unwanted-05.txt 2017-05-10 11:13:11.879851063 -0700 +++ 2/draft-ietf-sipcore-status-unwanted-06.txt 2017-05-10 11:13:11.899851547 -0700 @@ -1,18 +1,18 @@ SIPCORE H. Schulzrinne Internet-Draft FCC -Intended status: Standards Track April 19, 2017 -Expires: October 21, 2017 +Intended status: Standards Track May 8, 2017 +Expires: November 9, 2017 A SIP Response Code for Unwanted Calls - draft-ietf-sipcore-status-unwanted-05 + draft-ietf-sipcore-status-unwanted-06 Abstract This document defines the 607 (Unwanted) SIP response code, allowing called parties to indicate that the call or message was unwanted. SIP entities may use this information to adjust how future calls from this calling party are handled for the called party or more broadly. Status of This Memo @@ -22,21 +22,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on October 21, 2017. + This Internet-Draft will expire on November 9, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -50,22 +50,22 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Normative Language . . . . . . . . . . . . . . . . . . . . . 3 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Behavior of SIP Entities . . . . . . . . . . . . . . . . . . 3 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 5.1. SIP Response Code . . . . . . . . . . . . . . . . . . . . 5 5.2. SIP Global Feature-Capability Indicator . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction In many countries, an increasing number of calls are unwanted [RFC5039]: they might be fraudulent, illegal telemarketing or the receiving party does not want to be disturbed by, say, surveys or solicitation by charities. Carriers and other service providers may want to help their subscribers avoid receiving such calls, using a @@ -108,26 +108,24 @@ 3. Motivation None of the existing 4xx, 5xx or 6xx response codes signify that this SIP request is unwanted by the called party. For example, 603 (Decline) might be used if the called party is currently at dinner or in a meeting, but does not want to indicate any specific reason. As described in Section 21.6.2 [RFC3261], a 603 response may include a Retry-After header field to indicate a better time to attempt the call. Thus, the call is rejected due to the called party's - (temporary) disposition. As described in Section 4, the called party + (temporary) status. As described in Section 4, the called party invokes the "unwanted call" user interface and 607 (Unwanted) response indicating that it is instead the caller's identity that is - causing the call to be rejected. The particular response code number - was chosen to reflect the distaste felt by many upon receiving such - calls. + causing the call to be rejected. 4. Behavior of SIP Entities The response code 607 MAY be used in a failure response for an INVITE, MESSAGE, SUBSCRIBE or other out-of-dialog SIP request to indicate that the offered communication is unwanted. The response code MAY also be used as the value of the "cause" parameter of a SIP reason-value in a Reason header field [RFC3326], typically when the called party user agent issues a BYE request terminating an incoming call or a forking proxy issues a CANCEL request after receiving a 607 @@ -140,33 +138,40 @@ The SIP entities receiving this response code are not obligated to take any particular action beyond those appropriate for 6xx responses. Following the default handling for 6xx responses in [RFC5057], the 607 response destroys the transaction. The service provider delivering calls or messages to the user issuing the response MAY take a range of actions, for example, add the calling party to a personal blacklist specific to the called party, use the information as input when computing the likelihood that the calling party is placing unwanted calls ("crowd sourcing"), initiate a traceback request, or report the calling party identity to consumer - complaint databases operated by government authorities. + complaint databases. As discussed in Section Section 6, reversing + the 'unwanted' labeling is beyond the scope of this mechanism, as it + will likely require a mechanism other than call signaling. The user experience is envisioned to be somewhat similar to email spam buttons where the detailed actions of the email provider remain opaque to the user. - Call handling for unwanted calls is likely to involve a combination - of heuristics, analytics, and machine learning. These may use call - characteristics such as call duration and call volumes for a - particular caller, as well changes in those metrics over time, as - well as user feedback. Implementations will have to make appropriate - trade-offs between falsely labeling a caller as unwanted and - delivering unwanted calls. + The mechanism described here is only one of many inputs likely to be + used by call filtering algorithms operated by service providers, + using data on calls from a particular identifier such as a telephone + number to establish handling for future calls from the same + identifier. Call handling for unwanted calls is likely to involve a + combination of heuristics, analytics, and machine learning. These + may use call characteristics such as call duration and call volumes + for a particular caller, including changes in those metrics over + time, as well as user feedback via non-SIP approaches and the + mechanism described here. Implementations will have to make + appropriate trade-offs between falsely labeling a caller as unwanted + and delivering unwanted calls. Systems receiving 607 responses could decide to treat pre-call and mid-call responses differently, given that the called party has had access to call content for mid-call rejections. Depending on the implementation, the response code does not necessarily automatically block all calls from that caller identity. The same user interface action might also trigger addition of the caller identity to a local, on-device blacklist or graylist, e.g., causing such calls to be flagged or alerted with a different ring @@ -244,45 +249,50 @@ blacklist. For example, the list may be shown on a web page or the subscriber may be notified by periodic email reminders. Any additions to a global or carrier-wide list of unwanted callers needs to consider that any user-initiated mechanism will suffer from an unavoidable rate of false positives and tailor their algorithms accordingly, e.g., by comparing the fraction of delivered calls for a particular caller that are flagged as unwanted rather than just the absolute number, and considering time-weighted filters that give more credence to recent feedback. + If an attacker on an unsecured network can spoof SIP responses for a + significant number of call recipients, it may be able to convince the + call filtering algorithm to block legitimate calls. Use of TLS to + protect signaling mitigates against this risk. + Since caller identities are routinely re-assigned to new subscribers, algorithms are advised to consider whether the caller identity has been re-assigned to a new subscriber and possibly reset any related rating. (In some countries, there are services that track which telephone numbers have been disconnected before they are re-assigned to a new subscriber.) - Some call services such as 3PCC [RFC3725] and call transfer [RFC3665] + Some call services such as 3PCC [RFC3725] and call transfer [RFC5359] increase the complexity of identifying who (if anyone) should be impacted by the receipt of 607 within BYE. Such services might cause the wrong party to be flagged or prevent flagging the desired party. For both individually-authenticated and unauthenticated calls, recipients of response code 607 may want to distinguish responses sent before and after the call has been answered, ascertaining whether either response timing suffers from a lower false-positive rate. 7. Acknowledgements - Tolga Asveren, Ben Campbell, Peter Dawes, Martin Dolly, Keith Drage, - Vijay Gurbani, Christer Holmberg, Olle Johansson, Paul Kyzivat, Jean - Mahoney, Marianne Mohali, Adam Montville, Al Morton, Denis Ovsienko, - Brian Rosen, Brett Tate, Chris Wendt, Dale Worley and Peter Yee (Gen- - ART reviewer) provided helpful comments. + Tolga Asveren, Ben Campbell, Peter Dawes, Spencer Dawkins, Martin + Dolly, Keith Drage, Vijay Gurbani, Christer Holmberg, Olle Johansson, + Paul Kyzivat, Jean Mahoney, Marianne Mohali, Adam Montville, Al + Morton, Denis Ovsienko, Brian Rosen, Brett Tate, Chris Wendt, Dale + Worley and Peter Yee (Gen-ART reviewer) provided helpful comments. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . @@ -309,42 +319,42 @@ Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, "Authenticated Identity Management in the Session Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16 (work in progress), February 2017. [RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, DOI 10.17487/RFC3323, November 2002, . - [RFC3665] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and - K. Summers, "Session Initiation Protocol (SIP) Basic Call - Flow Examples", BCP 75, RFC 3665, DOI 10.17487/RFC3665, - December 2003, . - [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004, . [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, DOI 10.17487/RFC3966, December 2004, . [RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation Protocol (SIP) and Spam", RFC 5039, DOI 10.17487/RFC5039, January 2008, . [RFC5057] Sparks, R., "Multiple Dialog Usages in the Session Initiation Protocol", RFC 5057, DOI 10.17487/RFC5057, November 2007, . + [RFC5359] Johnston, A., Ed., Sparks, R., Cunningham, C., Donovan, + S., and K. Summers, "Session Initiation Protocol Service + Examples", BCP 144, RFC 5359, DOI 10.17487/RFC5359, + October 2008, . + Author's Address Henning Schulzrinne FCC 445 12th Street SW Washington, DC 20554 US Email: henning.schulzrinne@fcc.gov