Skip to main content

A SIP Response Code for Unwanted Calls

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 8197.
Author Henning Schulzrinne
Last updated 2016-12-12
RFC stream Internet Engineering Task Force (IETF)
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state Became RFC 8197 (Proposed Standard)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
SIPCORE                                                   H. Schulzrinne
Internet-Draft                                                       FCC
Intended status: Standards Track                       December 12, 2016
Expires: June 15, 2017

                 A SIP Response Code for Unwanted Calls


   This document defines the 666 (Unwanted) SIP response code, allowing
   called parties to indicate that the call was unwanted.  The
   terminating SIP entity may use this information to adjust future call
   handling behavior for this 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

   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 June 15, 2017.

Copyright Notice

   Copyright (c) 2016 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
   ( 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 June 15, 2017                 [Page 1]
Internet-Draft               Status Unwanted               December 2016

Table of Contents

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

1.  Introduction

   In many countries, an increasing number of calls are unwanted
   [RFC5039], as 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 request, typically INVITE or
   MESSAGE, as unwanted or terminates the call 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 party or a automata acting on her behalf uses this
   to indicate that future calls from the same caller are also unwanted.

2.  Normative Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in BCP 14, RFC 2119

3.  Motivation

   None of the existing 4xx, 5xx or 6xx response codes allow the called
   party to convey that they not only reject this call, e.g., using 480
   (Temporarily Unavailable), 486 (Busy Here), 600 (Busy Everywhere),
   603 (Decline) or 606 (Not Acceptable), but that the caller is

Schulzrinne               Expires June 15, 2017                 [Page 2]
Internet-Draft               Status Unwanted               December 2016

   unwanted.  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 MAY also be used in Reason header fields [RFC3326],
   typically when the UAS issues a BYE request terminating an incoming

   The SIP entities receiving this response code are not obligated to
   take any particular action.  The service provider delivering calls to
   the user issuing the response may, for example, add the calling party
   to a personal blacklist specific to the called party, or may use the
   information as input when computing the likelihood that the calling
   party is placing unwanted calls ("crowd sourcing"), might initiate a
   traceback request, or could report the calling number to government
   authorities.  Receiving systems 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 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
   be flagged or alert with a different ring tone.

   We define a SIP feature-capability [RFC6809], sip.666, that allows
   the registrar to indicate that it 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 register a new SIP response code.  This response code
   is defined by the following information, which is to be added to the
   method and response-code sub-registry under

   Response Code Number  666

   Default Reason Phrase  Unwanted

Schulzrinne               Expires June 15, 2017                 [Page 3]
Internet-Draft               Status Unwanted               December 2016

   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

   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]

6.  Security Considerations

   If the calling party number is spoofed, users may report the number
   as placing unwanted calls, possibly leading to the blocking of calls
   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
   response code SHOULD NOT be used for creating global call filters
   unless the calling party number 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 number is not spoofed, a call recipient might flag
   legitimate numbers, e.g., to extract vengeance on a person or
   business, or simply by mistake.  Thus, any additions to a personal
   list of blocked numbers should be observable by the subscriber, e.g.,
   on a web page or by regular email notification, and reservible.  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 telephone numbers are routinely re-assigned to new subscribers,
   algorithms are advised to consider whether the number has been re-
   assigned to a new subscriber and possibly reset any related rating.

   For both individually-authenticated and unauthenticated calls,
   recipients may want to distinguish responses sent before and after

Schulzrinne               Expires June 15, 2017                 [Page 4]
Internet-Draft               Status Unwanted               December 2016

   the call has been answered, ascertaining whether either response
   timing suffers from a lower false-positive rate.

7.  Acknowledgements

   Martin Dolly, Keith Drage, Paul Kyzivat, Brian Rosen and Chris Wendt
   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,

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

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

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

8.2.  Informative References

              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.

   [RFC5039]  Rosenberg, J. and C. Jennings, "The Session Initiation
              Protocol (SIP) and Spam", RFC 5039, DOI 10.17487/RFC5039,
              January 2008, <>.

Schulzrinne               Expires June 15, 2017                 [Page 5]
Internet-Draft               Status Unwanted               December 2016

Author's Address

   Henning Schulzrinne
   445 12th Street SW
   Washington, DC  20554


Schulzrinne               Expires June 15, 2017                 [Page 6]