Subject: [sipcore] draft-ietf-sipcore-status-unwanted-02: 666 vs. 603

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 8 Feb 2017 21:21:41 +0000

One clean-up item that needs wordsmithing:

If my recollection of the discussion is correct, we seem to mostly agree on a few points:

*         The most likely user interface triggering a 666 is something that looks like a spam button. It hangs up the call, ringing or in progress, but it is distinct from (say) a do-not-disturb response, which would like trigger a 603 status, or just a plain "call over" BYE without any Reason.

*         In general, due to user familiarity, behavior that's very roughly equivalent to email spam buttons or the emerging apps (Hiya and Android dialer, to name two) that have such a UI feature, seems preferable.

*         Based on a long discussion, we seem to agree that the actions taken by the terminating carrier (i.e., the carrier serving the user receiving the unwanted call) are implementation-specific and may be somewhat opaque to the user, just like they are for email spam. Various analytics, heuristics and machine learning will enter into the picture, combined with data sources and signals other than 666 responses, but details will evolve and don't need to be and should not be standardized.

*         We agree that, in some cases, callers are not uniquely identified by the From header or PAI, although there is probably some disagreement as to how common (say) call forwarding is for robocalls, particularly in ways that matter. (If the spammer gets a complicit third party to forward calls, if that third party gets black-listed, that's probably a feature, not a bug.)

*         In general, there will be false positives of individual spam indicators, just as they are for email, whether due to fat-fingering or due to mis-interpreting the call. Standards can't prevent that, but this is not a new problem, and subject to implementation-specific trade-offs.

*         We agree that unauthenticated numbers may, by spoofing, implicate innocent third parties.

However, to provide clarity to implementers and others, we can't just imply by "you know what I mean" that spam buttons and 666 MAY have consequences beyond a call. Thus, to make it clear what the role of the response code is and how it differs from other 6xx or 4xx status codes, indicating that the user intends to imply that he or she prefers not to hear from this caller again, seems helpful, recognizing that the user may not understand that "this caller" may be technically ambiguous in some cases.

If you strongly disagree, please let the list know - or if you think that this is "close enough". (I don't expect more than rough consensus here...) Wording that is sufficiently clear without being overly prescriptive is also appreciated.

Wording suggestion: "... and indicates that the called party does not wish to hear from this caller again. (Forwarding, spoofing and other causes may make uniquely identifying the caller difficult in some cases.)"

I'd like to close this out soon that we can move this along.

Henning

---

From: "Dawes, Peter, Vodafone Group" <[email-masked]>
Date: Thu, 9 Feb 2017 09:21:13 +0000

Hello Henning,
I agree with your bullet points, and I think that some words are needed to indicate that the spam button affects future calls and not just the current call (I'm not sure if this is what you are asking for agreement on, but I guess that you are referring to this discussion https://mailarchive.ietf.org/arch/msg/sipcore/zCoG9TSs5L4L7awa4CIqvJh7LNI).

If you are referring below to the last sentence of the Introduction, then distinguishing  protocol ( 'caller identity', 'calling party identity' etc.) from people ('caller') might make it clearer, such as:

The called user agent (UAS), prompted by input from the called party or based on UA-internal logic, sends a 666 (Unwanted) response to indicate that the calling identity should be added to filtering algorithms that screen calls. (Forwarding, spoofing and other causes may make determining the calling identity responsible for the unwanted call difficult in some cases.)

Regards,
Peter

From: sipcore [mailto:[email-masked]] On Behalf Of Henning Schulzrinne
Sent: 08 February 2017 21:22
To: SIPCORE
Subject: [sipcore] draft-ietf-sipcore-status-unwanted-02: 666 vs. 603

Henning

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 09 Feb 2017 11:03:07 -0500

Henning Schulzrinne <[email-masked]> writes:
> [...]
> * Based on a long discussion, we seem to agree that the actions taken
> by the terminating carrier (i.e., the carrier serving the user
> receiving the unwanted call) are implementation-specific and may be
> somewhat opaque to the user, just like they are for email
> spam. Various analytics, heuristics and machine learning will enter
> into the picture, combined with data sources and signals other than
> 666 responses, but details will evolve and don't need to be and should
> not be standardized.
> 
> * We agree that, in some cases, callers are not uniquely identified by
> the From header or PAI, although there is probably some disagreement
> as to how common (say) call forwarding is for robocalls, particularly
> in ways that matter. (If the spammer gets a complicit third party to
> forward calls, if that third party gets black-listed, that's probably
> a feature, not a bug.)
> 
> * In general, there will be false positives of individual spam
> indicators, just as they are for email, whether due to fat-fingering
> or due to mis-interpreting the call. Standards can't prevent that, but
> this is not a new problem, and subject to implementation-specific
> trade-offs.
> 
> However, to provide clarity to implementers and others, we can't just
> imply by "you know what I mean" that spam buttons and 666 MAY have
> consequences beyond a call. Thus, to make it clear what the role of
> the response code is and how it differs from other 6xx or 4xx status
> codes, indicating that the user intends to imply that he or she
> prefers not to hear from this caller again, seems helpful, recognizing
> that the user may not understand that "this caller" may be technically
> ambiguous in some cases.

It seems to me that your description, starting from bullet point 3 and
continuing through the first paragraph after the bullet points (the
portion I've quoted above), is a great summary of the situation.  And it
seems to me that a very good way to communicate to the reader the
implications of 666 is to insert that text into the draft more or less
whole (possibly adding the first two bullet points).

> Wording suggestion: "... and indicates that the called party does not
> wish to hear from this caller again. (Forwarding, spoofing and other
> causes may make uniquely identifying the caller difficult in some
> cases.)"

I think this particular wording, like the previous wording, has the
fault of trying to compress a fairly complex situation into one or two
sentences without losing vital details.  And that fault is what your
"few points" description avoids.

Dale

---

From: Adam Roach <[email-masked]>
Date: Thu, 9 Feb 2017 14:25:07 -0600

[as an individual]

I think this is a good path forward. In my mind, the distinction is:

603 indicates that there is something about the *callee's* disposition 
that prevents the call from being accepted, which is why retrying later 
is likely to work ("it's not you; it's me").

666 indicates that there is something about the *caller's* disposition 
that prevents the call from being accepted, and that future attempts 
will almost certainly receive a 666 as well. The network can infer that 
other callees are likely to consider similar calls to have the same 
disposition, especially if it can detect a pattern of such rejections.

So, in terms of your proposed language, maybe something like: "...and 
indicates 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."

Dale's point that inclusion of some of the rationale below (perhaps in 
an appendix?) might be useful in making the purpose and rationale for 
the new code clear.

/a

On 2/8/17 15:21, Henning Schulzrinne wrote:
> ·The most likely user interface triggering a 666 is something that 
> looks like a spam button. It hangs up the call, ringing or in 
> progress, but it is distinct from (say) a do-not-disturb response, 
> which would like trigger a 603 status, or just a plain “call over” BYE 
> without any Reason.
>
> ·In general, due to user familiarity, behavior that’s very roughly 
> equivalent to email spam buttons or the emerging apps (Hiya and 
> Android dialer, to name two) that have such a UI feature, seems 
> preferable.
>
> ·Based on a long discussion, we seem to agree that the actions taken 
> somewhat opaque to the user, just like they are for email spam. 
> Various analytics, heuristics and machine learning will enter into the 
> picture, combined with data sources and signals other than 666 
> responses, but details will evolve and don’t need to be and should not 
> be standardized.
>
> ·We agree that, in some cases, callers are not uniquely identified by 
> forward calls, if that third party gets black-listed, that’s probably 
> a feature, not a bug.)
>
> ·In general, there will be false positives of individual spam 
> or due to mis-interpreting the call. Standards can’t prevent that, but 
> ·We agree that unauthenticated numbers may, by spoofing, implicate 
> innocent third parties.
>
> However, to provide clarity to implementers and others, we can’t just 
> imply by “you know what I mean” that spam buttons and 666 MAY have 
> that the user may not understand that “this caller” may be technically 
> ambiguous in some cases.
>
> If you strongly disagree, please let the list know – or if you think 
> that this is “close enough”. (I don’t expect more than rough consensus 
> here…) Wording that is sufficiently clear without being overly 
> prescriptive is also appreciated.
>
> Wording suggestion: /“… and indicates that the called party does not 
> cases.)”/
> I’d like to close this out soon that we can move this along.
>
> Henning
>
>
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore