A SIP Response Code for Unwanted Calls
Extracted elements (18)
Reversing an 'unwanted' label is considered out of scope for this mechanism, as it will likely require a mechanism other than call signaling. Service providers handling global or carrier-wide lists must account for unavoidable false-positive rates and use fraction-based rather than absolute count metrics.
The 607 code was introduced because no existing 4xx, 5xx, or 6xx response codes signify that a SIP request is unwanted by the called party. The 603 (Decline) code indicates the called party's temporary status, not the caller's identity as the reason for rejection.
The mechanism is analogous to email spam buttons where detailed provider actions remain opaque to the user. It is intended as one of many inputs to call-filtering algorithms combining heuristics, analytics, and machine learning.
The presence of the sip.607 feature capability does not imply the provider will take any particular action such as blocking future calls. A UA may still render a 'spam' button without the capability if it maintains a device-local blacklist or reports to a third party.
Anonymous SIP URIs (RFC 3323) may be used by multiple callers and are therefore unlikely to be appropriate targets for URI-specific call treatment when tallying 607 responses. SIP entities may need to canonicalize SIP URIs including telephone numbers.
Services such as 3PCC (RFC 3725) and call transfer (RFC 5359) increase the complexity of identifying who should be impacted by receipt of 607 within BYE, and may cause the wrong party to be flagged or prevent flagging the intended party.
Systems receiving 607 responses may treat pre-call and mid-call responses differently, since the called party has had access to call content for mid-call rejections, which may imply different false-positive rates.
The 607 response code MAY also be used as the value of the 'cause' parameter of a SIP reason-value in a Reason header field, typically when the called party UA issues a BYE request or a forking proxy issues a CANCEL after receiving a 607 response from one branch.
The 607 response code 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.
A SIP feature-capability indicator 'sip.607' is defined, allowing a registrar to advertise in a REGISTER response that the corresponding proxy supports the 607 response code. This enables UAs to conditionally expose user-interface elements such as a 'spam' button.
Following default handling for 6xx responses per RFC 5057, the 607 response destroys the transaction. SIP entities receiving this response are not obligated to take any particular action beyond those appropriate for 6xx responses.
The 607 (Unwanted) SIP response code is defined to allow called parties to indicate that an incoming call or message was unwanted. It signals that future attempts from the same calling party are likely to be similarly rejected.
A new SIP response code 607 with description 'Unwanted' is registered in the 'Response Codes' subregistry under the 'Session Initiation Protocol (SIP) Parameters' registry.
The feature capability indicator 'sip.607' is registered in the 'SIP Feature-Capability Indicator Registration Tree' registry (RFC 6809). When included in a Feature-Caps header field of a REGISTER response, it indicates server support for the 607 response code.
An attacker on an unsecured network who can spoof SIP responses for a significant number of call recipients may manipulate call-filtering algorithms to block legitimate calls. Use of TLS to protect signaling mitigates this risk.
Even with legitimate (non-spoofed) identity, recipients might flag legitimate callers in error or maliciously. Personal blacklist additions should be observable and reversible by the protected party, e.g., via a web page or periodic email notifications.
If the calling party address is spoofed, users may falsely report the caller identity, potentially blocking legitimate users of that identity — a form of denial-of-service. The 607 response code SHOULD NOT be used for creating global call filters unless the calling party identity has been authenticated per SIP-IDENTITY.
Since caller identities are routinely reassigned to new subscribers, filtering algorithms should consider whether a caller identity has been reassigned and possibly reset associated ratings to avoid penalizing new subscribers.