SIPCORE                                                   H. Schulzrinne
Internet-Draft                                                       FCC
Intended status: Standards Track                           March 2,                          April 19, 2017
Expires: September 3, October 21, 2017

                 A SIP Response Code for Unwanted Calls
                 draft-ietf-sipcore-status-unwanted-04
                 draft-ietf-sipcore-status-unwanted-05

Abstract

   This document defines the 666 607 (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 September 3, October 21, 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Normative Language  . . . . . . . . . . . . . . . . . . . . .   3
   3.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Behavior of SIP Entities  . . . . . . . . . . . . . . . . . .   3
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
     5.1.  SIP Response Code . . . . . . . . . . . . . . . . . . . .   5
     5.2.  SIP Global Feature-Capability Indicator . . . . . . . . .   5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7   8

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 feedback within the last mode, where SIP
   call.  Here, the called party either rejects the SIP [RFC3261] request, typically
   requests using the INVITE or MESSAGE methods,
   request as unwanted or terminates the session with a BYE request
   after answering the call.  INVITE and MESSAGE requests are most
   likely to trigger such a response.

   To allow the called party to express that the call was unwanted, this
   document defines the 666 607 (Unwanted) response code.  The called user agent (UAS), of
   the called party, based on input from the called party or some UA-internal UA-
   internal logic, uses this to indicate that this call is unwanted and
   that 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"
   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
   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.  For example, 603
   (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
   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 607 (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

   The response code 666 607 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
   called party user agent issues a BYE request terminating an incoming
   call or the UAC a forking proxy issues a CANCEL request when forking after receiving a call. 607
   response from one of the branches.  (Including a Reason header field
   with the 666 607 status code allows the UAS called party user agent that
   receives a CANCEL request to make an informed choice whether and how
   to include such calls in their missed-call list.) list or whether to show an
   appropriate indication to the user.)

   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 607 response destroys the transaction.  The service
   provider delivering calls or messages to the user issuing the
   response,
   response MAY take a range of actions, 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 or report the calling party identity to consumer
   complaint databases operated by government authorities.

   This specification does not mandate any particular action by SIP
   entities and leaves those

   The user experience is envisioned to implementations. be somewhat similar to email
   spam buttons where the detailed actions of the email provider remain
   opaque to the user.

   Call handling for unwanted calls is likely to involve a combination
   of heuristics, analytics, and machine learning, based on user feedback, learning.  These may use call
   characteristics such as call duration and call volumes, volumes for a
   particular caller, as well changes in such metrics. those metrics over time, as
   well as user feedback.  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 607 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

   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
   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, sip.607,
   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 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  607

   Default Reason Phrase  Unwanted

   Reference  [this RFC]

5.2.  SIP Global Feature-Capability Indicator

   This document defines the feature capability sip.666 sip.607 in the "SIP
   Feature-Capability Indicator Registration Tree" registry defined in
   [RFC6809].

   Name  sip.666  sip.607

   Description  This feature-capability indicator indicator, when used included in a
      Feature-Caps header field of a REGISTER response response, indicates that
      the server supports, and will process process, the 666 607 (Unwanted) response
      code.  This does not imply any specific action.

   Reference  [this RFC]

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 exact 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.  (In some countries, there are services that track which
   telephone numbers have been disconnected before they are re-assigned
   to a new subscriber.)

   Some call services such as 3PCC [RFC3725] and call transfer [RFC3665]
   increase the complexity of identifying who (if anyone) should be
   impacted by the receipt of 666 607 within BYE.  Such services might cause
   the wrong party to be flagged or prevent flagging the desired party.

   For both individually-authenticated and unauthenticated calls,
   recipients of response code 666 607 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, Ben Campbell, Peter Dawes, Martin Dolly, Keith Drage,
   Vijay Gurbani, Christer Holmberg, Olle Johansson, Paul Kyzivat, Jean
   Mahoney, Marianne Mohali, Adam Montville, Al Morton, Denis Ovsienko,
   Brian Rosen, Brett Tate, Chris Wendt and Wendt, Dale Worley and Peter Yee (Gen-
   ART reviewer) provided helpful comments.

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>.

   [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-16
              (work in progress), February 2017.

   [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>.

   [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.
              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",
              RFC 3966, DOI 10.17487/RFC3966, December 2004,
              <http://www.rfc-editor.org/info/rfc3966>.

   [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>.

   [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>.

Author's Address

   Henning Schulzrinne
   FCC
   445 12th Street SW
   Washington, DC  20554
   US

   Email: henning.schulzrinne@fcc.gov