A SIP Response Code for Unwanted Calls

In many countries, an increasing number of calls are unwanted , 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.

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 .

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 unwanted. The particular response code number was chosen to reflect the distaste felt by many upon receiving such calls.

The response code MAY also be used in Reason header fields , typically when the UAS issues a BYE request terminating an incoming call. 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 , 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.

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 http://www.iana.org/assignments/sip-parameters. 666 Unwanted [this RFC]

This document defines the feature capability sip.666 in the "SIP Feature-Capability Indicator Registration Tree" registry defined in . sip.666 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. [this RFC]

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 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 the call has been answered, ascertaining whether either response timing suffers from a lower false-positive rate.

Martin Dolly, Keith Drage, Paul Kyzivat, Brian Rosen and Chris Wendt provided helpful comments.