draft-ietf-sipcore-status-unwanted-00.txt | draft-ietf-sipcore-status-unwanted-01.txt | |||
---|---|---|---|---|
SIPCORE H. Schulzrinne | SIPCORE H. Schulzrinne | |||
Internet-Draft FCC | Internet-Draft FCC | |||
Intended status: Standards Track December 12, 2016 | Intended status: Standards Track January 4, 2017 | |||
Expires: June 15, 2017 | Expires: July 8, 2017 | |||
A SIP Response Code for Unwanted Calls | A SIP Response Code for Unwanted Calls | |||
draft-ietf-sipcore-status-unwanted-00 | draft-ietf-sipcore-status-unwanted-01 | |||
Abstract | Abstract | |||
This document defines the 666 (Unwanted) SIP response code, allowing | This document defines the 666 (Unwanted) SIP response code, allowing | |||
called parties to indicate that the call was unwanted. The | called parties to indicate that the call was unwanted. SIP entities | |||
terminating SIP entity may use this information to adjust future call | may use this information to adjust how future calls from this calling | |||
handling behavior for this called party or more broadly. | party are handled for the called party or more broadly. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
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 June 15, 2017. | This Internet-Draft will expire on July 8, 2017. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2016 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 | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
2. Normative Language . . . . . . . . . . . . . . . . . . . . . 2 | 2. Normative Language . . . . . . . . . . . . . . . . . . . . . 2 | |||
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2 | 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
4. Behavior of SIP Entities . . . . . . . . . . . . . . . . . . 3 | 4. Behavior of SIP Entities . . . . . . . . . . . . . . . . . . 3 | |||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 | |||
5.1. SIP Response Code . . . . . . . . . . . . . . . . . . . . 3 | 5.1. SIP Response Code . . . . . . . . . . . . . . . . . . . . 4 | |||
5.2. SIP Global Feature-Capability Indicator . . . . . . . . . 4 | 5.2. SIP Global Feature-Capability Indicator . . . . . . . . . 4 | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 | |||
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 | 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 | |||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
8.1. Normative References . . . . . . . . . . . . . . . . . . 5 | 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 | |||
8.2. Informative References . . . . . . . . . . . . . . . . . 5 | 8.2. Informative References . . . . . . . . . . . . . . . . . 6 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
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], as 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 | |||
variety of global or user-specific filtering algorithms. One input | variety of global or user-specific filtering algorithms. One input | |||
into such algorithms is user feedback. User feedback may be offered | into such algorithms is user feedback. User feedback may be offered | |||
through smartphone apps, APIs or within the context of a SIP- | through smartphone apps, APIs or within the context of a SIP- | |||
initiated call. This document addresses only the last mode, where | initiated call. This document addresses only the last mode, where | |||
the called party either rejects the SIP request, typically INVITE or | the called party either rejects the SIP [RFC3261] request, typically | |||
MESSAGE, as unwanted or terminates the call with a BYE request after | requests using the INVITE or MESSAGE methods, as unwanted or | |||
answering the call. To allow the called party to express that the | terminates the call with a BYE request after answering the call. To | |||
call was unwanted, this document defines the 666 (Unwanted) response | allow the called party to express that the call was unwanted, this | |||
code. The called party or a automata acting on her behalf uses this | document defines the 666 (Unwanted) response code. The called user | |||
to indicate that future calls from the same caller are also unwanted. | agent (UAS), based on input from the called party or some UA-internal | |||
logic, uses this to indicate that future calls from the same caller | ||||
are also unwanted. | ||||
2. Normative Language | 2. Normative Language | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in BCP 14, RFC 2119 | document are to be interpreted as described in BCP 14, RFC 2119 | |||
[RFC2119]. | [RFC2119]. | |||
3. Motivation | 3. Motivation | |||
None of the existing 4xx, 5xx or 6xx response codes allow the called | None of the existing 4xx, 5xx or 6xx response codes signify that | |||
party to convey that they not only reject this call, e.g., using 480 | calls from this caller are unwanted by the called party. The | |||
(Temporarily Unavailable), 486 (Busy Here), 600 (Busy Everywhere), | particular response code number was chosen to reflect the distaste | |||
603 (Decline) or 606 (Not Acceptable), but that the caller is | felt by many upon receiving such calls. | |||
unwanted. The particular response code number 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 MAY also be used in Reason header fields [RFC3326], | The response code 666 MAY be used in a failure response for an | |||
typically when the UAS issues a BYE request terminating an incoming | INVITE, MESSAGE, SUBSCRIBE or other out-of-dialog SIP request to | |||
call. | 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 | ||||
UAS issues a BYE or CANCEL request terminating an incoming call. | ||||
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. The service provider delivering calls to | take any particular action. The service provider delivering calls to | |||
the user issuing the response may, for example, add the calling party | the user issuing the response, for example, MAY add the calling party | |||
to a personal blacklist specific to the called party, or may use the | to a personal blacklist specific to the called party, MAY 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"), might initiate a | party is placing unwanted calls ("crowd sourcing"), MAY initiate a | |||
traceback request, or could report the calling number to government | traceback request, and MAY report the calling number to government | |||
authorities. Receiving systems could decide to treat pre-call and | authorities. | |||
mid-call responses differently, given that the called party has had | ||||
access to call content for mid-call rejections. In other words, | Receiving systems could decide to treat pre-call and mid-call | |||
depending on the implementation, the response code does not | responses differently, given that the called party has had access to | |||
necessarily automatically block all calls from that number. The same | call content for mid-call rejections. In other words, depending on | |||
user interface action might also trigger addition of the number to a | the implementation, the response code does not necessarily | |||
automatically block all calls from that number. The same user | ||||
interface action might also trigger addition of the number to a | ||||
local, on-device blacklist or graylist, e.g., causing such calls to | local, on-device blacklist or graylist, e.g., causing such calls to | |||
be flagged or alert with a different ring tone. | be flagged or alerted with a different ring tone. | |||
The actions described here do not depend on the nature of the SIP | ||||
URI, e.g., whether it describes a telephone number or not; however, | ||||
the same anonymous SIP URI [RFC3323] may be used by multiple callers | ||||
and thus such URIs are unlikely to be appropriate for URI-specific | ||||
call treatment. SIP entities tallying responses for particular | ||||
callers may need to consider canonicalzing SIP URIs, including | ||||
telephone numbers, as described in [I-D.ietf-stir-rfc4474bis]. | ||||
We define a SIP feature-capability [RFC6809], sip.666, that allows | We define a SIP feature-capability [RFC6809], sip.666, that allows | |||
the registrar to indicate that it supports this particular response | the registrar to indicate that the corresponding proxy supports this | |||
code. This allows the UA, for example, to provide a suitable user | particular response code. This allows the UA, for example, to | |||
interface element, such as a "spam" button, only if its service | provide a suitable user interface element, such as a "spam" button, | |||
provider actually supports the feature. The presence of the feature | only if its service provider actually supports the feature. The | |||
capability does not imply that the provider will take any particular | presence of the feature capability does not imply that the provider | |||
action, such as blocking future calls. A UA may still decide to | will take any particular action, such as blocking future calls. A UA | |||
render a "spam" button even without such as a capability if, for | may still decide to render a "spam" button even without such as a | |||
example, it maintains a device-local blacklist or reports unwanted | capability if, for example, it maintains a device-local blacklist or | |||
calls to a third party. | reports unwanted calls to a third party. | |||
5. IANA Considerations | 5. IANA Considerations | |||
5.1. SIP Response Code | 5.1. SIP Response Code | |||
This document register a new SIP response code. This response code | This document registers a new SIP response code. This response code | |||
is defined by the following information, which is to be added to the | is defined by the following information, which is to be added to the | |||
method and response-code sub-registry under | "Response Codes" sub-registry under http://www.iana.org/assignments/ | |||
http://www.iana.org/assignments/sip-parameters. | sip-parameters. | |||
Response Code Number 666 | Response Code Number 666 | |||
Default Reason Phrase Unwanted | Default Reason Phrase Unwanted | |||
Reference [this RFC] | Reference [this RFC] | |||
5.2. SIP Global Feature-Capability Indicator | 5.2. SIP Global Feature-Capability Indicator | |||
This document defines the feature capability sip.666 in the "SIP | This document defines the feature capability sip.666 in the "SIP | |||
Feature-Capability Indicator Registration Tree" registry defined in | Feature-Capability Indicator Registration Tree" registry defined in | |||
[RFC6809]. | [RFC6809]. | |||
Name sip.666 | Name sip.666 | |||
skipping to change at page 4, line 34 ¶ | skipping to change at page 4, line 48 ¶ | |||
from the legitimate user of the number in addition to the unwanted | from the legitimate user of the number in addition to the unwanted | |||
caller, i.e., creating a form of denial-of-service attack. Thus, the | caller, i.e., creating a form of denial-of-service attack. Thus, the | |||
response code SHOULD NOT be used for creating global call filters | response code SHOULD NOT be used for creating global call filters | |||
unless the calling party number has been authenticated using | unless the calling party number has been authenticated using | |||
[I-D.ietf-stir-rfc4474bis] as being assigned to the caller placing | [I-D.ietf-stir-rfc4474bis] as being assigned to the caller placing | |||
the unwanted call. (The creation of call filters local to a user | the unwanted call. (The creation of call filters local to a user | |||
agent is beyond the scope of this document.) | agent is beyond the scope of this document.) | |||
Even if the number is not spoofed, a call recipient might flag | Even if the number is not spoofed, a call recipient might flag | |||
legitimate numbers, e.g., to extract vengeance on a person or | legitimate numbers, e.g., to extract vengeance on a person or | |||
business, or simply by mistake. Thus, any additions to a personal | business, or simply by mistake. To correct errors, any additions to | |||
list of blocked numbers should be observable by the subscriber, e.g., | a personal list of blocked numbers should be observable and | |||
on a web page or by regular email notification, and reservible. Any | reversible by the party being protected by the blacklist. For | |||
additions to a global or carrier-wide list of unwanted callers needs | example, the list may be shown on a web page or the subscriber may be | |||
to consider that any user-initiated mechanism will suffer from an | notified by periodic email reminders. Any additions to a global or | |||
unavoidable rate of false positives and tailor their algorithms | carrier-wide list of unwanted callers needs to consider that any | |||
accordingly, e.g., by comparing the fraction of delivered calls for a | user-initiated mechanism will suffer from an unavoidable rate of | |||
particular caller that are flagged as unwanted rather than just the | false positives and tailor their algorithms accordingly, e.g., by | |||
absolute number, and considering time-weighted filters that give more | comparing the fraction of delivered calls for a particular caller | |||
credence to recent feedback. | that are flagged as unwanted rather than just the absolute number, | |||
and considering time-weighted filters that give more credence to | ||||
recent feedback. | ||||
Since telephone numbers are routinely re-assigned to new subscribers, | Since telephone numbers are routinely re-assigned to new subscribers, | |||
algorithms are advised to consider whether the number has been re- | algorithms are advised to consider whether the number has been re- | |||
assigned to a new subscriber and possibly reset any related rating. | assigned to a new subscriber and possibly reset any related rating. | |||
For both individually-authenticated and unauthenticated calls, | For both individually-authenticated and unauthenticated calls, | |||
recipients may want to distinguish responses sent before and after | recipients may want to distinguish responses sent before and after | |||
the call has been answered, ascertaining whether either response | the call has been answered, ascertaining whether either response | |||
timing suffers from a lower false-positive rate. | timing suffers from a lower false-positive rate. | |||
7. Acknowledgements | 7. Acknowledgements | |||
Martin Dolly, Keith Drage, Paul Kyzivat, Brian Rosen and Chris Wendt | Tolga Asveren, Peter Dawes, Martin Dolly, Keith Drage, Vijay Gurbani, | |||
Paul Kyzivat, Jean Mahoney, Brian Rosen, Chris Wendt and Dale Worley | ||||
provided helpful comments. | 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 5, line 46 ¶ | skipping to change at page 6, line 13 ¶ | |||
<http://www.rfc-editor.org/info/rfc6809>. | <http://www.rfc-editor.org/info/rfc6809>. | |||
8.2. Informative References | 8.2. Informative References | |||
[I-D.ietf-stir-rfc4474bis] | [I-D.ietf-stir-rfc4474bis] | |||
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-15 | Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-15 | |||
(work in progress), October 2016. | (work in progress), October 2016. | |||
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session | ||||
Initiation Protocol (SIP)", RFC 3323, | ||||
DOI 10.17487/RFC3323, November 2002, | ||||
<http://www.rfc-editor.org/info/rfc3323>. | ||||
[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>. | |||
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 | |||
End of changes. 21 change blocks. | ||||
61 lines changed or deleted | 83 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/ |