Subject: [sipcore] I-D Action: draft-ietf-sipcore-callinfo-spam-00.txt

From: [email-masked]
Date: Tue, 07 Mar 2017 12:47:49 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Core of the IETF.

        Title           : SIP Call-Info Parameters for Labeling Calls
        Author          : Henning Schulzrinne
	Filename        : draft-ietf-sipcore-callinfo-spam-00.txt
	Pages           : 9
	Date            : 2017-03-07

Abstract:
   Called parties often wish to decide whether to accept, reject or
   redirect calls based on the likely nature of the call.  For example,
   they may want to reject unwanted telemarketing or fraudulent calls,
   but accept emergency alerts from numbers not in their address book.
   This document describes SIP Call-Info parameters and a feature tag
   that allow originating, intermediate and terminating SIP entities to
   label calls as to their type, spam probability and references to
   additional information.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-callinfo-spam/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-sipcore-callinfo-spam-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 17 Mar 2017 18:50:13 +0000

A few initial comments:

i- It may be useful to cover scenarios where the "spam nature" of the call can be determined only a while after call starts, e.g. based on speech analysis. This probably would require defining a new event package. Does this sound useful/needed?

ii- "type" parameter values seem over-specified to me. Actually overall I would think that what is needed as aggregate information is (indicated in corresponding parameters):
spam score
verified identity of the entity which decided the spam score (+ unverified identity of the entity which decided the spam score with an indication that it is not verified)

I am not sure I understand the practical use case for "reason" parameter and what type of values could be used there, therefore seems unnecessary to me.

Just trying to apply "Occam's Razor". I think it would be best to define what is really needed in a "as simple as possible but not simpler" way.

Thanks,
Tolga

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, March 7, 2017 3:48 PM
To: [email-masked]
Cc: [email-masked]
Subject: [sipcore] I-D Action: draft-ietf-sipcore-callinfo-spam-00.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 17 Mar 2017 20:19:23 +0000

(i) The notification is an interesting idea, but I wonder how much this would be used in practice. If the called party has already picked up, when would this add value? (Also, in many cases, mobile users won't see the screen at that point, given that they are talking on the phone.) I suspect for true scam calls, mid-call termination (BYE), e.g., for vulnerable populations, may be more effective.

(ii) The list was compiled by a group of industry participants, including lawyers. I actually don't think the spam score alone helps, given that some calls are likely ambiguous, such as surveys, charities (not-for-profit) and debt-collection - they may be spammy to you, but acceptable to others. I still would like to know if a charity is calling since I can probably defer answering when I'm at dinner or can auto-answer such calls when I'm traveling in a different time zone. (I may have given permission to be called, but not at 2 am local time.)

Also, in general, I don't think spam scores have proven all that useful in email, except very locally. There just isn't a good way to tell why something is a "6" vs. a "7". I think it works ok as a confidence indicator within a category - "I'm 70% certain that this is a charity call."

If you have a specific proposal of types that are not needed or that should be merged, please explain.

The reason parameter is motivated by email experience - it's really important for developers to be able to tell how the decision was reached. I don't think this will typically be made visible to users. As far as I know, all email filter indicators include some version of a "reason" field. In those cases, it's often a collection of filters that (say) SpamAssassin used. (If you look at their X-Spam-Score header, you'll see something like 0.01 HTML or T_REMOTE_IMAGE LOW_PRICE indicating why the email was rated that way.) Often, the SIP request will be routed through some external "oracle" (analytics) and you don't want this to be a complete black box, particularly if calls are getting mislabeled. (I suspect we'll see this more in enterprise deployments than in consumer usage.)

Henning

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Asveren, Tolga
Sent: Friday, March 17, 2017 2:50 PM
To: [email-masked]
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-callinfo-spam-00.txt

A few initial comments:

Thanks,
Tolga

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, March 7, 2017 3:48 PM
To: [email-masked]
Cc: [email-masked]
Subject: [sipcore] I-D Action: draft-ietf-sipcore-callinfo-spam-00.txt

Abstract:

The IETF datatracker status page for this draft is:
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dsipcore-2Dcallinfo-2Dspam_&d=DwICAg&c=y0h0omCe0jAUGr4gAQ02Fw&r=FJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=UmUs8Pe84oynK8LiSf2oV9iU9HfmKM-O2ORnd4HtaBM&s=T8v-YMJaYwTA2kYcBVnUaz-V6cXbwsOiGhCZEBl5LzE&e= 

There's also a htmlized version available at:
https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dsipcore-2Dcallinfo-2Dspam-2D00&d=DwICAg&c=y0h0omCe0jAUGr4gAQ02Fw&r=FJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=UmUs8Pe84oynK8LiSf2oV9iU9HfmKM-O2ORnd4HtaBM&s=pzEuOg9xKBqwbhaMniL2l1kSXZj8lnanrEYEI_6kJ4I&e= 

Internet-Drafts are also available by anonymous FTP at:
https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=DwICAg&c=y0h0omCe0jAUGr4gAQ02Fw&r=FJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=UmUs8Pe84oynK8LiSf2oV9iU9HfmKM-O2ORnd4HtaBM&s=AZfM7O8SbaBLtGuyW9Yqk-NSKY5Hdq13ap1hbsqQeHo&e= 

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

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

---

From: "Asveren, Tolga" <[email-masked]>
Date: Sat, 18 Mar 2017 08:58:08 +0000

I agree that "spam-score" does not have much value from end-user perspective. When I check the weather report, what I care is whether I should get my umbrella not the precise probability of rain. OTOH, I don't think the "nature of call" type of information would serve any practical purpose for end-user.

Stepping back and taking a somewhat more systematical approach:

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.

An indicator for asking the end-user to provide information about whether he considers the call as spam would be useful and should be covered IMHO. This would help Network Logic to learn/be more precise about heuristics applied for spam detection. I can see a few different scenarios here:
- Network decides to ask for feedback during initial INVITE, indicator can a be a parameter in Call-Info
- Network decides to ask for feedback after the call is setup, e.g. because it detects that the call could be spam by speech analysis. Indicator can be sent in BYE, if the call is terminated by the calling party. Otherwise -if BYE is sent by called party-, network can still send BYE with the indicator toward calling party before 200 for the BYE received from it. I think this should work. In either case, end-user could see a visual indicator asking whether the call was spam. If he honors the request, 200(BYE) would have the 666-unwanted. I am not sure what would be the best way to handle the situation that the end-user hangs-up and then notices the indicator and decides to send feedback. UE can cache the Call-Id but conveying Call-Id/this was(n't) a spam information to the network probably would require a new event package. Alternatively, UE can buffer 200(BYE) for a while after user hangs up -to give the user the opportunity to notice the indicator and act- but that may have issues from billing perspective (maybe a "delayed = x sec" parameter added to 200(BYE) could help).

Thanks,
Tolga

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Friday, March 17, 2017 4:19 PM
To: Asveren, Tolga <[email-masked]>; [email-masked]
Subject: RE: [sipcore] I-D Action: draft-ietf-sipcore-callinfo-spam-00.txt

Henning

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Asveren, Tolga
Sent: Friday, March 17, 2017 2:50 PM
To: [email-masked]
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-callinfo-spam-00.txt

A few initial comments:

Thanks,
Tolga

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, March 7, 2017 3:48 PM
To: [email-masked]
Cc: [email-masked]
Subject: [sipcore] I-D Action: draft-ietf-sipcore-callinfo-spam-00.txt

Abstract: