draft-ietf-sipcore-status-unwanted-02.txt   draft-ietf-sipcore-status-unwanted-03.txt 
SIPCORE H. Schulzrinne SIPCORE H. Schulzrinne
Internet-Draft FCC Internet-Draft FCC
Intended status: Standards Track January 12, 2017 Intended status: Standards Track February 15, 2017
Expires: July 16, 2017 Expires: August 19, 2017
A SIP Response Code for Unwanted Calls A SIP Response Code for Unwanted Calls
draft-ietf-sipcore-status-unwanted-02 draft-ietf-sipcore-status-unwanted-03
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 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 July 16, 2017. This Internet-Draft will expire on August 19, 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
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 . . . . . . . . . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Behavior of SIP Entities . . . . . . . . . . . . . . . . . . 3 4. Behavior of SIP Entities . . . . . . . . . . . . . . . . . . 3
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
5.1. SIP Response Code . . . . . . . . . . . . . . . . . . . . 4 5.1. SIP Response Code . . . . . . . . . . . . . . . . . . . . 5
5.2. SIP Global Feature-Capability Indicator . . . . . . . . . 4 5.2. SIP Global Feature-Capability Indicator . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
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
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 [RFC3261] request, typically the called party either rejects the SIP [RFC3261] request, typically
requests using the INVITE or MESSAGE methods, as unwanted or requests using the INVITE or MESSAGE methods, as unwanted or
terminates the session with a BYE request after answering the call. terminates the session with a BYE request after answering the call.
To allow the called party to express that the call was unwanted, this To allow the called party to express that the call was unwanted, this
document defines the 666 (Unwanted) response code. The called user document defines the 666 (Unwanted) response code. The called user
agent (UAS), based on input from the called party or some UA-internal 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 logic, uses this to indicate that this call is unwanted and that
are also unwanted. future attempts are likely to be similarly rejected. While factors
such as identity spoofing and call forwarding may make authoritative
identification of the calling party difficult or impossible, the
network can use such a rejection -- possibly combined with a pattern
of rejections by other callees and/or other information -- as input
to a heuristic algorithm for determining future call treatment. The
heuristic processing and possible treatment of persistently unwanted
calls are outside the scope of this document.
As in [I-D.ietf-stir-rfc4474bis], we use the term "caller identity" As in [I-D.ietf-stir-rfc4474bis], we use the term "caller identity"
or "calling party identity" in this document to mean either a or "calling party identity" in this document to mean either a
canonical address-of-record (AoR) SIP URI employed to reach a user canonical address-of-record (AoR) SIP URI employed to reach a user
(such as 'sip:alice@atlanta.example.com'), or a telephone number, (such as 'sip:alice@atlanta.example.com'), or a telephone number,
which commonly appears in either a tel URI [RFC3966] or as the user which commonly appears in either a tel URI [RFC3966] or as the user
portion of a SIP URI. portion of a SIP URI.
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 signify that this None of the existing 4xx, 5xx or 6xx response codes signify that this
SIP request is unwanted by the called party. The particular response SIP request is unwanted by the called party. For example, 603
code number was chosen to reflect the distaste felt by many upon (Decline) might be used if the called party is currently at dinner or
receiving such calls. 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
invokes the "unwanted call" user interface and 666 (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.
4. Behavior of SIP Entities 4. Behavior of SIP Entities
The response code 666 MAY be used in a failure response for an The response code 666 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
UAS issues a BYE request terminating an incoming call or the UAC UAS issues a BYE request terminating an incoming call or the UAC
issues a CANCEL request when forking a call. (Including a Reason issues a CANCEL request when forking a call. (Including a Reason
skipping to change at page 3, line 38 skipping to change at page 4, line 7
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 666 response destroys the transaction. The service [RFC5057], the 666 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, for example, MAY add the calling party to a personal response, for example, MAY add the calling party to a personal
blacklist specific to the called party, MAY use the information as blacklist specific to the called party, MAY use the information as
input when computing the likelihood that the calling party is placing input when computing the likelihood that the calling party is placing
unwanted calls ("crowd sourcing"), MAY initiate a traceback request, unwanted calls ("crowd sourcing"), MAY initiate a traceback request,
and MAY report the calling party identity to government authorities. and MAY report the calling party identity to government authorities.
This specification does not mandate any particular action by SIP
entities and leaves those to implementations. Call handling for
unwanted calls is likely to involve a combination of heuristics,
analytics, machine learning, based on user feedback, call
characteristics such as call duration and call volumes, as well
changes in such metrics. Implementations will have to make
appropriate trade-offs between falsely labeling a caller as unwanted
and delivering unwanted calls. 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.
Systems receiving 666 responses could decide to treat pre-call and Systems receiving 666 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. In other words, access to call content for mid-call rejections. In other words,
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
tone. tone.
skipping to change at page 5, line 37 skipping to change at page 6, line 17
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.
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. rating.
Some call services such as 3PCC [RFC3725] and call transfer increase
the complexity of identifying who (if anyone) should be impacted by
the receipt of 666 within BYE. Such services might causes 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 666 may want to distinguish responses recipients of response code 666 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, Peter Dawes, Martin Dolly, Keith Drage, Vijay Gurbani, Tolga Asveren, Peter Dawes, Martin Dolly, Keith Drage, Vijay Gurbani,
Olle Johansson, Paul Kyzivat, Jean Mahoney, Marianne Mohali, Brian Olle Johansson, Paul Kyzivat, Jean Mahoney, Marianne Mohali, Brian
skipping to change at page 6, line 40 skipping to change at page 7, line 25
Indicate Support of Features and Capabilities in the Indicate Support of Features and Capabilities in the
Session Initiation Protocol (SIP)", RFC 6809, Session Initiation Protocol (SIP)", RFC 6809,
DOI 10.17487/RFC6809, November 2012, DOI 10.17487/RFC6809, November 2012,
<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-16
(work in progress), October 2016. (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>.
[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,
<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>.
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. 14 change blocks. 
18 lines changed or deleted 55 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/