Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - general

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 19 Jul 2017 15:45:27 +0000

Tolga,

Sorry for missing your comment and thank you for re-starting the conversation.

Let me try to respond in general terms first, as I think your assumptions differ a bit from mine.

There are three general observations:

  1.  Call spam is somewhat subjective, partially reflected in the unwanted vs. illegal distinction. There are clearly calls that are illegal (e.g., the tax authority scams) and presumably unwanted (if the called party knew that it was a scam). But there are many calls that are somewhat less clear. Calls by politicians or debt collectors are two classical examples - they may be legal, but a significant fraction of people would rather not get these calls or may not want to answer these calls at certain times. As another example, a called party may decide that they'd rather not be bothered with any non-personal calls ("robocalls") during their vacation or while traveling in a different time zone, even if they'd otherwise be happy to get the call (e.g., calls about prescriptions being ready for pickup). They may also decide to send these calls to voicemail.
  2.  As Paul points out in a follow-up message, only the end user is qualified to make these distinctions (or, somewhat equivalently, an algorithm configured by the end user that reflects her personal preferences).
  3.  Because of these subtleties, many carriers would rather not get into the call dropping business and leave that to the end user, with exceptions. (For example, they may want to drop denial-of-service or spoofed caller ID calls.)

The 'type' information helps the called party or the algorithm working on her behalf to make decisions.

I don't quite understand the "identity of the entity providing spam score" comment. The 'source' element is meant to provide this. Can you explain how your identity differs from the one in the draft?

Similarly, you write "A "0-100 spam score" indicator may be useful in this context...". The 'spam' parameter in the draft contains this information. Again, can you explain how your proposal differs from the draft? [That said, I'm tempted to rename the parameter to 'confidence', to be less prejudicial.]

Henning

From: Asveren, Tolga [mailto:[email-masked]]
Sent: Wednesday, July 19, 2017 4:35 AM
To: Henning Schulzrinne <[email-masked]>; [email-masked]
Subject: RE: draft-ietf-sipcore-callinfo-spam-01 - SIP entities

Henning,

I had some high level queries/comments, which I sent back beginning of April. Here it is again for easier access:

What are the main use cases?
1) Communicating spam related information between network elements for a particular call
Various network elements may have a prediction whether a call is spam. It could be useful to send all that info in a chain and then the ultimate decision what needs to be sent to UE would be on the last-hop authorative entity. A "0-100 spam score" indicator may be useful in this context, or at least something more than just "likely to be spam" indicator.
The identity of the entity providing spam score needs to be part of the provided information.
More than one spam score/identity pair needs to be supported.
Support for signed identity should be there.
I am not sure whether "type" would be useful here, I tend to think not. How/Why would it be used?

2) Communicating spam related information between network and end-user
I think here what is needed is just a "likely to be spam" indicator as far as network prediction is concerned. End-user would see a visual indicator if the indicator is present. Anything more than that is just "information overdose" IMHO and wouldn't have much practical value for an average user. Another indicator stating "calling identity can't be verified" could be useful but this IMHO is something different.

[Trimming separate issue]

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 21 Jul 2017 13:57:10 +0000

Henning,

Inline...

Thanks,
Tolga

From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Wednesday, July 19, 2017 11:45 AM
To: Asveren, Tolga <[email-masked]>; [email-masked]
Subject: RE: draft-ietf-sipcore-callinfo-spam-01 - general

Tolga,

  1.  Call spam is somewhat subjective, partially reflected in the unwanted vs. illegal distinction. There are clearly calls that are illegal (e.g., the tax authority scams) and presumably unwanted (if the called party knew that it was a scam). But there are many calls that are somewhat less clear. Calls by politicians or debt collectors are two classical examples - they may be legal, but a significant fraction of people would rather not get these calls or may not want to answer these calls at certain times. As another example, a called party may decide that they'd rather not be bothered with any non-personal calls ("robocalls") during their vacation or while traveling in a different time zone, even if they'd otherwise be happy to get the call (e.g., calls about prescriptions being ready for pickup). They may also decide to send these calls to voicemail.
  2.  As Paul points out in a follow-up message, only the end user is qualified to make these distinctions (or, somewhat equivalently, an algorithm configured by the end user that reflects her personal preferences).
[TOLGA] I think what you are describing here gets a bit out of the "annoying calls" category. It is more related with "call categorization in general". Do we really want to tackle such a broad topic in this draft? I thought the raison d'etre is dealing with robocalls, spam. I personally would prefer to keep focus on these aspects.

  1.  Because of these subtleties, many carriers would rather not get into the call dropping business and leave that to the end user, with exceptions. (For example, they may want to drop denial-of-service or spoofed caller ID calls.)

I don't quite understand the "identity of the entity providing spam score" comment. The 'source' element is meant to provide this. Can you explain how your identity differs from the one in the draft?
[TOLGA] Yes, what I described is covered by "source", I just wanted to express my opinion for which scenarios/use case it would be useful, i.e. between network elements and not much toward the end-device.

Similarly, you write "A "0-100 spam score" indicator may be useful in this context...". The 'spam' parameter in the draft contains this information. Again, can you explain how your proposal differs from the draft? [That said, I'm tempted to rename the parameter to 'confidence', to be less prejudicial.]
[TOLGA] Again, I was just trying to point out that a fine granularity spam indicator could be useful among network entities but not so much toward the end-device.

Henning

From: Asveren, Tolga [mailto:[email-masked]]
Sent: Wednesday, July 19, 2017 4:35 AM
To: Henning Schulzrinne <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: draft-ietf-sipcore-callinfo-spam-01 - SIP entities

Henning,

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 21 Jul 2017 18:27:12 +0000

I think we beat the other issues to death, where, if I may say so, your opinion seems to be on the rough side of the consensus.

For the 'type' designation, the list is motivated by the real-life observation that robocalls come in, to use your term, shades of annoying. The current strategy in many households is not to answer any calls where the caller name isn't a family member, which is not ideal. (For example, your bank robot may be calling you to alert you to a suspicious charge on your debit card.) Thus arose the notion of labeling calls that are robocalls (or, more generally, non-personal calls) with more granularity. Otherwise, you end up either rejecting or labeling all non-personal calls or only fraudulent "IRS scam" calls.

The list of labels, as noted in the acknowledgments section of the draft, was compiled by members of the Robocall Strike Force that met last year, so this is not my personal invention. Task force members were struggling with the issue I mentioned above, where a simple binary good/bad indicator is likely to be either over-inclusive or under-inclusive for many called parties.

As noted, you can implement a simple "spam-or-not" mechanism using only the type='spam' catch-all, if that's your implementation preference.

[TOLGA] I think what you are describing here gets a bit out of the “annoying calls” category. It is more related with “call categorization in general”. Do we really want to tackle such a broad topic in this draft? I thought the raison d’etre is dealing with robocalls, spam. I personally would prefer to keep focus on these aspects.

Henning

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 21 Jul 2017 18:36:09 +0000

Understood that the list is not coming out of thin air; I just thought that it refers to a broader range of issues outside of the scope of the draft. But then it seems I am on the minority as far as that view is concerned. That parameters are optional is comforting though.

So, overall, I am resting my case.

Thanks,
Tolga

From: sipcore [mailto:[email-masked]] On Behalf Of Henning Schulzrinne
Sent: Friday, July 21, 2017 2:27 PM
To: Asveren, Tolga <[email-masked]>; [email-masked]
Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - general

Henning