Subject: [sipcore] draft-ietf-sipcore-status-unwanted -- do we need another response code?

From: [email-masked] (Dale R. Worley)
Date: Thu, 05 Jan 2017 16:14:31 -0500

Given that 666 responses can cause later calls to be blocked by
automated mechanisms, do we need a (different) response code to indicate
"this call has been blocked by an automated spam-prevention system"?  It
seems to me that we need a mechanism to inform the caller that he may
need to initiate an exception procedure to prevent his calls from being
blocked.

Dale

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Thu, 5 Jan 2017 21:24:09 +0000

Dale

By automated mechanisms only with consumer consent. Consumer is in control

Regards

Martin C. Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards
AT&T
Cell: +1.609.903.3360<tel:+1.609.903.3360>
Email: [email-masked]<mailto:[email-masked]>

On Jan 5, 2017, at 4:14 PM, Dale R. Worley <[email-masked]<mailto:[email-masked]>> wrote:

Dale

_______________________________________________
sipcore mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sipcore

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 5 Jan 2017 22:33:42 +0000

Are you talking about the case where the end system itself does the blocking, e.g., via an app (e.g., Hiya or Nomorobo)?

Leaving aside Martin's concerns for a moment, I admit that I'm not convinced that this distinction is meaningful. For example, an app or dialer may have a personal blacklist (I believe Android does). This is something done by the user, not AI (so Martin may like it...), but the dialer would be responding with a 666 on the next call to signal the reason for the rejection. Is that a robot instead? What if the app just suggests that this is a "bad" call and the user hits the spam button? I admit that I have a hard time drawing a firm line that would provide sufficient guidance to implementors to choose one status code or the other.

This seems like something we could discuss once we have a bit more operational experience. Maybe a "Warning" code would be the more appropriate means of conveying such additional information, for example.

Henning

________________________________
From: sipcore <[email-masked]> on behalf of Dale R. Worley <[email-masked]>
Sent: Thursday, January 5, 2017 4:14:31 PM
To: [email-masked]
Subject: [sipcore] draft-ietf-sipcore-status-unwanted -- do we need another response code?

Dale

_______________________________________________
sipcore mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_sipcore&d=DgICAg&c=y0h0omCe0jAUGr4gAQ02Fw&r=FJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=lUklkBNSKO8leDczj7XpUsgIjfeHd5JAaPgSZ1mkcek&s=a5GMBGa2toS86AJ3-GyP_piMbHog9ESqx6zHiig5nTI&e=

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 06 Jan 2017 10:04:31 -0500

Henning Schulzrinne <[email-masked]> writes:
> Are you talking about the case where the end system itself does the
> blocking, e.g., via an app (e.g., Hiya or Nomorobo)?
>
> Leaving aside Martin's concerns for a moment, I admit that I'm not
> convinced that this distinction is meaningful. For example, an app or
> dialer may have a personal blacklist (I believe Android does). This is
> something done by the user, not AI (so Martin may like it...), but the
> dialer would be responding with a 666 on the next call to signal the
> reason for the rejection. Is that a robot instead? What if the app
> just suggests that this is a "bad" call and the user hits the spam
> button? I admit that I have a hard time drawing a firm line that would
> provide sufficient guidance to implementors to choose one status code
> or the other.

I'm using a model that resembles how I think spam filtering works:  the
user's SIP service monitors the calls for which the user triggers 666.
Based on this, it constructs a filter for which calls will be presented
to the user.  The calls that are rejected aren't rejected specifically
because the user has specified that they are to be rejected, but based
on the filter.  So there will be occasional mistakes.  It seems like it
would be useful to notify the caller that the call was rejected based on
such a filter.

> This seems like something we could discuss once we have a bit more
> operational experience. Maybe a "Warning" code would be the more
> appropriate means of conveying such additional information, for
> example.

Hmmm, looking at the drarft again, the specifics of blocking, or even
whether blocking is done, are out of scope.  But I like your proposal of
a Warning code.  And we might need more than one Warning code, if this
situation turns out to be more complicated.

Dale

---

From: "Asveren, Tolga" <[email-masked]>
Date: Sun, 8 Jan 2017 17:46:36 +0000

Inline...

Thanks,
Tolga

> -----Original Message-----
> From: sipcore [mailto:[email-masked]] On Behalf Of Dale R. Worley
> Sent: Friday, January 06, 2017 10:05 AM
> To: Henning Schulzrinne <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted -- do we need
> another response code?
> 
> I'm using a model that resembles how I think spam filtering works:  the user's
> SIP service monitors the calls for which the user triggers 666.
> Based on this, it constructs a filter for which calls will be presented to the
> user.  The calls that are rejected aren't rejected specifically because the user
> has specified that they are to be rejected, but based on the filter.  So there
> will be occasional mistakes.  It seems like it would be useful to notify the
> caller that the call was rejected based on such a filter.
> 
> Hmmm, looking at the drarft again, the specifics of blocking, or even whether
> blocking is done, are out of scope.  But I like your proposal of a Warning code.
> And we might need more than one Warning code, if this situation turns out
> to be more complicated.
[TOLGA] I don't think there is a difference between a call being rejected by the user pushing the "Spam button" v.s. the call being auto-rejected because of a list prepared by the user and residing *only* in the UE. Both of them have the same meaning: The user does not want this call. And they would should be treated the same as far as the logic in network is concerned. A "blocking list" maintained by the user, e.g. through a Web Portal, and known by the network logic would be a different story: That probably would cause the call to be blocked before it is even sent to the UE. I am strongly in favor of keeping "666 unwanted" consistent with the semantics of "This call is unwanted by the user" rather than overloading it.

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 09 Jan 2017 10:47:27 -0500

"Asveren, Tolga" <[email-masked]> writes:
> [TOLGA] I don't think there is a difference between a call being
> rejected by the user pushing the "Spam button" v.s. the call being
> auto-rejected because of a list prepared by the user and residing
> *only* in the UE. Both of them have the same meaning: The user does
> not want this call. And they would should be treated the same as far
> as the logic in network is concerned. A "blocking list" maintained by
> the user, e.g. through a Web Portal, and known by the network logic
> would be a different story: That probably would cause the call to be
> blocked before it is even sent to the UE.

True, but my point is that in practice, a fraction of rejected calls
will not be rejected based on absolute criteria specified by the user
but by probabilistic mechanisms that are trained by past input from the
user.  In that case, it's worth telling the originator that the
rejection was probabilistic rather than absolute.

> I am strongly in favor of keeping "666 unwanted" consistent with the
> semantics of "This call is unwanted by the user" rather than
> overloading it.

But as has been noted before, this draft isn't about the rejection
mechanism, but how the user can communicate upstream his specific
rejection of one call.

Dale

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 9 Jan 2017 16:02:10 +0000

> From: Dale R. Worley [mailto:[email-masked]]
> Sent: Monday, January 09, 2017 10:47 AM
> To: Asveren, Tolga <[email-masked]>
> Cc: [email-masked]
> True, but my point is that in practice, a fraction of rejected calls will not be
> rejected based on absolute criteria specified by the user but by probabilistic
> mechanisms that are trained by past input from the user.  In that case, it's
> worth telling the originator that the rejection was probabilistic rather than
> absolute.
[TOLGA] I think "666 unwanted" should cover only deterministic cases. And actually I doubt any heuristic mechanism would reside in UE itself without knowledge from the network intelligence. I would think that heuristic analysis is a functionality to be performed by network.
> But as has been noted before, this draft isn't about the rejection mechanism,
> but how the user can communicate upstream his specific rejection of one
> call.
[TOLGA] Yes, and IMHO there is only one reason why such a rejection happens -in the context of "666 unwanted": "The user considers this particular call as spam/unwanted."

---

From: Ranjit Avasarala <[email-masked]>
Date: Mon, 9 Jan 2017 11:18:45 -0600

Hi Dale

true - this draft is about indication - but how do we ensure the unwanted
caller is actually blocked?

Thanks
Ranjit

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 10 Jan 2017 23:36:11 +0000

I think we have rough consensus that, for now, the 666 code is meant for the "don't want this call" user behavior.

Longer term, I suspect we can revisit how to indicate that a network call filter made the decision, recognizing that the boundaries are a bit fluid as device capabilities and AI mature. Imagine an advanced machine learning bot trained on my personal preferences that I trust to make call decisions for me (reject, voicemail, have a robot-to-robocaller conversation to see whether the robocaller can tell, tell the caller that I'm driving). Is that a human decision (I trained the bot!) or robot?

I don't think we need to settle now whether this is 666 + Warning, some new 6xx code or an existing 6xx (or even 4xx) + Warning.

I think this is one aspect where email spam and VoIP robocall rejection differ: Because of the asynchronous nature of email, a human user can't really refuse and return the email once it's been delivered, so you can only indicate "spam!" for future filtering. Because of the real-time nature of calls, the two aspects (hinting to the call filter and indication to the caller) naturally blend a bit more than they would in email.

In any event, unless somebody has a concrete proposal (preferably one that doesn't double the draft size...), I think this is "beyond the scope of this draft".

Henning

-----Original Message-----
From: Dale R. Worley [mailto:[email-masked]] 
Sent: Friday, January 06, 2017 10:05 AM
To: Henning Schulzrinne <[email-masked]>
Cc: [email-masked]
Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted -- do we need another response code?

> provide sufficient guidance to implementors to choose one status code 

I'm using a model that resembles how I think spam filtering works:  the user's SIP service monitors the calls for which the user triggers 666.
Based on this, it constructs a filter for which calls will be presented to the user.  The calls that are rejected aren't rejected specifically because the user has specified that they are to be rejected, but based on the filter.  So there will be occasional mistakes.  It seems like it would be useful to notify the caller that the call was rejected based on such a filter.

> appropriate means of conveying such additional information, for 

Hmmm, looking at the drarft again, the specifics of blocking, or even whether blocking is done, are out of scope.  But I like your proposal of a Warning code.  And we might need more than one Warning code, if this situation turns out to be more complicated.

Dale