RFC 8197

A SIP Response Code for Unwanted Calls

📅 published July 2017, from ietf

RFC 8197: A SIP Response Code for Unwanted Calls 🎀

Okay bestie, this is RFC 8197, and it's giving official. 💅 It's a Standards Track doc from the Internet Engineering Task Force (IETF), written by H. Schulzrinne at the FCC and dated July 2017. It's ISSN 2070-1721, and it's part of the Internet Standards Track, so it's the real deal. ✨

Abstract 💜

This doc defines the 607 (Unwanted) SIP response code, which lets called parties say that a call or message was unwanted. SIP entities can use that info to adjust how future calls from this calling party get handled for the called party, or more broadly. 🦋

Status of This Memo 🌸

This is an Internet Standards Track document. 💖

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 7841.

You can find info about the current status of this document, any errata, and how to give feedback on it at http://www.rfc-editor.org/info/rfc8197. 🔥

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) as in effect on the date of publication of this document. Please review these documents carefully, because 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 they 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 . . . . . . . . . . . . . . . . . . .   6
7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
  7.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
  7.2.  Informative References  . . . . . . . . . . . . . . . . .   7
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   8
Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

1. Introduction ✨

Okay so, in lots of countries more and more calls are unwanted [RFC5039]. 😭 They could be fraudulent or illegal telemarketing, or the receiving party just doesn't want to be disturbed by surveys or charity solicitations. Carriers and other service providers may want to help their subscribers avoid these calls, using a variety of global or user-specific filtering algorithms. One input into those algorithms is user feedback. User feedback may be offered through smartphone apps, APIs, or within the context of a SIP-initiated call.

This doc is all about feedback within the SIP call 📞. Here, the called party either rejects the SIP [RFC3261] 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 let the called party say that the call was unwanted, this document defines the 607 (Unwanted) response code. The user agent (UA) of the called party uses it, based on input from the called party or some UA-internal logic, to indicate that this call is unwanted and that future attempts are likely to be similarly rejected. Factors like identity spoofing and call forwarding may make authoritative identification of the calling party difficult or impossible, and that's a lot. 😵‍💫 Still, 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. 🔮

When this document says "caller identity," it uses "identity" in the same sense as [SIP-IDENTITY]. That means either a canonical address-of-record (AOR) SIP URI used to reach a user (such as sip:alice@atlanta.example.com), or a telephone number. Telephone numbers commonly show up in 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", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 🎀

3. Motivation 🦋

None of the existing 4xx, 5xx, or 6xx response codes signal 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 doesn't want to give 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 try the call again. So the call is rejected because of the called party's (temporary) status. ⏰

As described in Section 4, though, the called party invokes the "unwanted call" user interface, and the 607 (Unwanted) response says that it's actually the caller's identity causing the call to be rejected. That's the difference, babe. 👑

4. Behavior of SIP Entities 💖

The response code 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]. This is typical when the called party user agent issues a BYE request to terminate an incoming call, or when a forking proxy issues a CANCEL request after receiving a 607 response from one of the branches. (Including a Reason header field with the 607 status code lets the called party user agent that receives a CANCEL request make an informed choice about whether and how to include such calls in their missed-call 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 607 response destroys the transaction. 💥 The service provider delivering calls or messages to the user who issued the response MAY take a range of actions. For example, it may add the calling party to a personal blacklist specific to the called party, use the information as input when computing the likelihood that the calling party is placing unwanted calls ("crowd sourcing"), initiate a traceback request, or report the calling party's identity to consumer complaint databases. 🕵️‍♀️ As discussed in Section 6, reversing the 'unwanted' labeling is beyond the scope of this mechanism, since it will likely require a mechanism other than call signaling. 🚧

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

The mechanism described here is only one of many inputs likely to be used by call-filtering algorithms operated by service providers. Those algorithms use data on calls from a particular identifier, such as a telephone number, to set up handling for future calls from the same identifier. Call handling for unwanted calls is likely to involve a combination of heuristics, analytics, and machine learning. 🤖 These may use call characteristics such as call duration and call volumes for a particular caller, including changes in those metrics over time, as well as user feedback via non-SIP approaches and the mechanism described here. Implementations will have to make appropriate trade-offs between falsely labeling a caller as unwanted and delivering unwanted calls. ⚖️

Systems receiving 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. 🎧

Depending on the implementation, the response code does not necessarily block all calls from that caller identity automatically. The same user interface action might also add 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 don't depend on the nature of the SIP URI, e.g., whether or not it describes a telephone number. However, the same anonymous SIP URI [RFC3323] may be used by multiple callers, so such URIs are unlikely to be appropriate for URI-specific call treatment. 🫥 SIP entities tallying responses for particular callers may need to consider canonicalizing SIP URIs, including telephone numbers, as described in [SIP-IDENTITY]. 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 it may also be affected by diverting services. 🔀

This document defines a SIP feature-capability [RFC6809], sip.607, that lets the registrar indicate that the corresponding proxy supports this particular response code. 🏷️ That means the UA can, for example, show 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. 🙌

Part 1 done, bestie! 🌈 Part 2 picks up with Section 5 (IANA Considerations 📋), then Security Considerations, References, Acknowledgements, and Author's Address. Stay tuned 💜

6. Security Considerations 🔐💅

okay bestie, this section is SO important so pay attention 👀✨ the whole vibe is "don't let your block list become a weapon" 😭🫶

If the calling party address is spoofed, users may report the caller identity as placing unwanted calls 📵, and that can lead to blocking calls from the legitimate user of that caller identity too, along with the unwanted caller. Literally a denial-of-service attack in disguise 💀. So the response code SHOULD NOT be used for creating global call filters unless the calling party identity has been authenticated using [SIP-IDENTITY] as being assigned to the caller placing the unwanted call. (Making call filters that only live on one user agent is beyond the scope of this document 🧚.)

Even if the identity is not spoofed, a call or message recipient might flag legit caller identities 🙅‍♀️, like to get revenge on a person or business, or just by mistake 🙈. To fix 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 might be shown on a web page, or the subscriber might get periodic email reminders 📧. Any additions to a global or carrier-wide list of unwanted callers need to account for the fact that any user-initiated mechanism will suffer from an unavoidable rate of false positives 😤, so tailor the algorithms accordingly. For example, compare the fraction of delivered calls for a particular caller that get flagged as unwanted, rather than just the absolute number, and consider time-weighted filters that give more credence to recent feedback ⏰💖.

If an attacker on an unsecured network can spoof SIP responses for a significant number of call recipients, they might be able to convince the call-filtering algorithm to block legitimate calls 😱. Using TLS to protect signaling mitigates this risk 🔒✨.

Since caller identities are routinely reassigned to new subscribers, algorithms are advised to consider whether the caller identity has been reassigned 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 get reassigned to a new subscriber 🌍.)

Some call services, like 3PCC [RFC3725] and call transfer [RFC5359], make it way more complicated to figure out who (if anyone) should be impacted by receiving 607 within BYE 🌀. These services might cause the wrong party to get flagged, or stop the desired party from getting flagged 🙃.

For both individually authenticated and unauthenticated calls, recipients of response code 607 may want to tell apart responses sent before and after the call has been answered 🧐, and check whether either response timing has a lower false-positive rate 📊🦋.

7. References 📚🎀

7.1. Normative References 💜

7.2. Informative References 🌸

Acknowledgements 🫶

Tolga Asveren, Ben Campbell, Peter Dawes, Spencer Dawkins, 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, Dale Worley, and Peter Yee (Gen-ART reviewer) provided helpful comments 💖 the squad really showed up for this one 👑.

Author's Address 🧚

Henning Schulzrinne FCC 445 12th Street SW Washington, DC 20554 United States of America

Email: henning.schulzrinne@fcc.gov 📮

📦 where this page comes from