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/