[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]
Versions: (draft-schulzrinne-dispatch-status-unwanted)
00 01 02 03 04 05 06 RFC 8197
SIPCORE H. Schulzrinne
Internet-Draft FCC
Intended status: Standards Track January 12, 2017
Expires: July 16, 2017
A SIP Response Code for Unwanted Calls
draft-ietf-sipcore-status-unwanted-02
Abstract
This document defines the 666 (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
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
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 July 16, 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
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Schulzrinne Expires July 16, 2017 [Page 1]
Internet-Draft Status Unwanted January 2017
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Normative Language . . . . . . . . . . . . . . . . . . . . . 2
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Behavior of SIP Entities . . . . . . . . . . . . . . . . . . 3
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
5.1. SIP Response Code . . . . . . . . . . . . . . . . . . . . 4
5.2. SIP Global Feature-Capability Indicator . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
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
variety of global or user-specific filtering algorithms. One input
into such algorithms is user feedback. User feedback may be offered
through smartphone apps, APIs or within the context of a SIP-
initiated call. This document addresses only the last mode, where
the called party either rejects the SIP [RFC3261] request, typically
requests using the INVITE or MESSAGE methods, as unwanted or
terminates the session with a BYE request after answering the call.
To allow the called party to express that the call was unwanted, this
document defines the 666 (Unwanted) response code. The called user
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.
As in [I-D.ietf-stir-rfc4474bis], we use the term "caller identity"
or "calling party identity" in this document to mean either a
canonical address-of-record (AoR) SIP URI employed to reach a user
(such as 'sip:alice@atlanta.example.com'), or a telephone number,
which commonly appears in either a tel URI [RFC3966] or as the user
portion of a SIP URI.
2. Normative Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
Schulzrinne Expires July 16, 2017 [Page 2]
Internet-Draft Status Unwanted January 2017
document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119].
3. Motivation
None of the existing 4xx, 5xx or 6xx response codes signify that this
SIP request is unwanted by the called party. The particular response
code number was chosen to reflect the distaste felt by many upon
receiving such calls.
4. Behavior of SIP Entities
The response code 666 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
UAS issues a BYE request terminating an incoming call or the UAC
issues a CANCEL request when forking a call. (Including a Reason
header field with the 666 status code allows the UAS that receive a
CANCEL request to make an informed choice whether and how to include
such calls in their missed-call list.)
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 666 response destroys the transaction. The service
provider delivering calls or messages to the user issuing the
response, for example, MAY add the calling party to a personal
blacklist specific to the called party, MAY use the information as
input when computing the likelihood that the calling party is placing
unwanted calls ("crowd sourcing"), MAY initiate a traceback request,
and MAY report the calling party identity to government authorities.
Systems receiving 666 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. In other words,
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
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
Schulzrinne Expires July 16, 2017 [Page 3]
Internet-Draft Status Unwanted January 2017
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]. The
calling party may be identified in different locations in the SIP
header, e.g., the From header field, P-Asserted-Identity or History-
Info, and may also be affected by diverting services.
This document defines a SIP feature-capability [RFC6809], sip.666,
that allows the registrar to indicate that the corresponding proxy
supports this particular response code. This allows the UA, for
example, to provide a suitable user interface element, such as a
"spam" button, only if its service provider actually supports the
feature. The presence of the feature capability does not imply that
the provider will take any particular action, such as blocking future
calls. A UA may still decide to render a "spam" button even without
such as a capability if, for example, it maintains a device-local
blacklist or reports unwanted calls to a third party.
5. IANA Considerations
5.1. SIP 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
"Response Codes" sub-registry under http://www.iana.org/assignments/
sip-parameters.
Response Code Number 666
Default Reason Phrase Unwanted
Reference [this RFC]
5.2. SIP Global Feature-Capability Indicator
This document defines the feature capability sip.666 in the "SIP
Feature-Capability Indicator Registration Tree" registry defined in
[RFC6809].
Name sip.666
Description This feature-capability indicator when used in a
REGISTER response indicates that the server will process the 666
response code. This does not imply any specific action.
Reference [this RFC]
Schulzrinne Expires July 16, 2017 [Page 4]
Internet-Draft Status Unwanted January 2017
6. Security Considerations
If the calling party address is spoofed, users may report the caller
identity as placing unwanted calls, possibly leading to the blocking
of calls from the legitimate user of the caller identity in addition
to the unwanted caller, i.e., creating a form of denial-of-service
attack. Thus, the response code SHOULD NOT be used for creating
global call filters unless the calling party identity has been
authenticated using [I-D.ietf-stir-rfc4474bis] as being assigned to
the caller placing the unwanted call. (The creation of call filters
local to a user agent is beyond the scope of this document.)
Even if the identity is not spoofed, a call or message recipient
might flag legitimate caller identities, e.g., to extract vengeance
on a person or business, or simply by mistake. To correct errors,
any additions to a personal list of blocked caller identities should
be observable and reversible by the party being protected by the
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.
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.
For both individually-authenticated and unauthenticated calls,
recipients of response code 666 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, Peter Dawes, Martin Dolly, Keith Drage, Vijay Gurbani,
Olle Johansson, Paul Kyzivat, Jean Mahoney, Marianne Mohali, Brian
Rosen, Brett Tate, Chris Wendt and Dale Worley provided helpful
comments.
Schulzrinne Expires July 16, 2017 [Page 5]
Internet-Draft Status Unwanted January 2017
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,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>.
[RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason
Header Field for the Session Initiation Protocol (SIP)",
RFC 3326, DOI 10.17487/RFC3326, December 2002,
<http://www.rfc-editor.org/info/rfc3326>.
[RFC5057] Sparks, R., "Multiple Dialog Usages in the Session
Initiation Protocol", RFC 5057, DOI 10.17487/RFC5057,
November 2007, <http://www.rfc-editor.org/info/rfc5057>.
[RFC6809] Holmberg, C., Sedlacek, I., and H. Kaplan, "Mechanism to
Indicate Support of Features and Capabilities in the
Session Initiation Protocol (SIP)", RFC 6809,
DOI 10.17487/RFC6809, November 2012,
<http://www.rfc-editor.org/info/rfc6809>.
8.2. Informative References
[I-D.ietf-stir-rfc4474bis]
Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
"Authenticated Identity Management in the Session
Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-15
(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>.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, DOI 10.17487/RFC3966, December 2004,
<http://www.rfc-editor.org/info/rfc3966>.
Schulzrinne Expires July 16, 2017 [Page 6]
Internet-Draft Status Unwanted January 2017
[RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation
Protocol (SIP) and Spam", RFC 5039, DOI 10.17487/RFC5039,
January 2008, <http://www.rfc-editor.org/info/rfc5039>.
Author's Address
Henning Schulzrinne
FCC
445 12th Street SW
Washington, DC 20554
US
Email: henning.schulzrinne@fcc.gov
Schulzrinne Expires July 16, 2017 [Page 7]
Html markup produced by rfcmarkup 1.129b, available from
https://tools.ietf.org/tools/rfcmarkup/