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