Subject: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 18 Jul 2017 19:50:35 +0000

I'm finally addressing Christer's helpful comments in

https://www.ietf.org/mail-archive/web/sipcore/current/msg07851.html

and have submitted a new draft.

Christer noted that I used the term "SIP entities" several times. What I meant to say is "SIP proxies and B2BUAs that face the [end customer] user agent and are associated with a registrar" (as opposed to some random SBC in the core of the network). After all, only those elements should remove any untrusted call-info information in this case. If there's a better way than the current short-hand "SIP proxy or B2BUA", I'll gladly take suggestions.

I think I addressed all the comments pending, but if I missed anything, please remind me. Otherwise, this should be ready.

Henning

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 19 Jul 2017 08:34:37 +0000

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.

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

From: sipcore [mailto:[email-masked]] On Behalf Of Henning Schulzrinne
Sent: Tuesday, July 18, 2017 3:51 PM
To: [email-masked]
Subject: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities

Henning

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 Jul 2017 11:24:13 -0400

On 7/19/17 4:34 AM, Asveren, Tolga wrote:

> 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.

You seem to be making an assumption about where the intelligence is 
located and policy decisions are made.

What you are saying may be appropriate for a dumb device and/or a dumb 
user. But most phones that will do anything with this information can be 
smart, and so be subject to configuration by the user for preferences. 
I'd rather maximize the amount of information available to the end device.

	Thanks,
	Paul

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 19 Jul 2017 18:11:02 +0000

Let me ask this question then:
What would "spam with a likelihood of 47%" mean? Will the specification detail how this percentage need to be calculated? Otherwise how can the end-device take some action based on this value? One could argue that all these are "implementation dependent" but honestly I think this would just create confusion/chaos in practice and likely to be not useful.

Thanks,
Tolga

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Wednesday, July 19, 2017 11:24 AM
To: [email-masked]
Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities

> verified" could be useful but this IMHO is something different.

You seem to be making an assumption about where the intelligence is located and policy decisions are made.

What you are saying may be appropriate for a dumb device and/or a dumb user. But most phones that will do anything with this information can be smart, and so be subject to configuration by the user for preferences. 
I'd rather maximize the amount of information available to the end device.

	Thanks,
	Paul

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 19 Jul 2017 18:33:17 +0000

This type of labeling is very common for email spam filters. It's essentially the same as "There's a 47% chance of rain today." Except that meteorologists are smart enough not to say 47%, but rather 50%.

It is better than the "According to the polls, candidate H has an 89% chance of winning the election." (Any semblance of initials to real persons has a 1-in-26 chance of being made up.)

Theoretically, unlike for elections and somewhat similar to the weather case, this is testable: You could take all the 50% spam or rain predictions, check with some reliable metric (human or rain gauge) whether the spam or rain happened and compare your results, i.e., roughly one in two such predictions should indeed turn out to be spam or rain. (It's more complicated than that, but we're getting pretty close to the philosophical debate of what probabilities mean when making predictions, which is apparently a rather unsettled scientific question.)

To actually answer your question: I don't think this is useful except as a rough way for users to trade false-positive/false-negative penalties. For example, they may discard all 80%+ probability calls, route 30-80% calls to voicemail and ring the below-30% calls. The thresholds are arbitrary, but users may tune them based on experience ("all the calls in voicemail were spam, so I can go lower").

Some people pack an umbrella when there's a 20% chance of rain, others are more willing to risk getting wet. By the way, it is well-known that meteorologists over-predict rain since nobody complains if they did not get soaked.

Henning

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Asveren, Tolga
Sent: Wednesday, July 19, 2017 2:11 PM
To: Paul Kyzivat <[email-masked]>; [email-masked]
Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities

Thanks,
Tolga

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 19 Jul 2017 18:46:02 +0000

Agreed that this is somewhat about "philosophical aspects of priority". Having said that, I really feel not content with a fine-granularity indicator considering how in practice it would/could be generated especially considering all the operator/equipment/call scenario/deployment model combinations. It would be like, actually worse, than how sausages are prepared.

I am not religiously advocating a change toward a binary indicator (i.e. I wouldn't consider the current model as something "wrong") but IMHO that would be a more practical way of getting something useful at the end; just my 2 cents.

Thanks,
Tolga

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Wednesday, July 19, 2017 2:33 PM
To: Asveren, Tolga <[email-masked]>; Paul Kyzivat <[email-masked]>; [email-masked]
Subject: RE: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities

Henning

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Asveren, Tolga
Sent: Wednesday, July 19, 2017 2:11 PM
To: Paul Kyzivat <[email-masked]>; [email-masked]
Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities

Thanks,
Tolga

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 Jul 2017 16:40:47 -0400

On 7/19/17 2:33 PM, Henning Schulzrinne wrote:
> By the way, it is well-known that meteorologists over-predict rain since nobody complains if they did not get soaked.

Farmers who are deciding whether to water their fields may feel 
differently. Perhaps meteorologists in farm country bias their 
predictions the other way.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 Jul 2017 16:45:23 -0400

> I am not religiously advocating a change toward a binary indicator (i.e. I wouldn't consider the current model as something "wrong") but IMHO that would be a more practical way of getting something…

If those who are inserting the probabilities feel like you do then they 
can restrict themselves to inserting values 0, 50, 100, or whatever 
granularity they feel comfortable with.

	Thanks,
	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 19 Jul 2017 20:46:28 +0000

If a service provider wants to provide a binary indication using the draft, they can, by omitting the 'spam' probability indicator:

Call-Info: ... ;purpose=info ;type=spam

Or

Call-Info: ... ;purpose=info ;type=personal

for non-spam.

Henning

-----Original Message-----
From: Asveren, Tolga [mailto:[email-masked]] 
Sent: Wednesday, July 19, 2017 2:46 PM
To: Henning Schulzrinne <[email-masked]>; Paul Kyzivat <[email-masked]>; [email-masked]
Subject: RE: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities

Thanks,
Tolga

---

From: Richard Shockey <[email-masked]>
Date: Thu, 20 Jul 2017 12:22:15 -0400

The other issue is who is the intended recipient of the data?  Among those of us that are actively evaulating Call Validation Display options we see some differences.  What a consumer may need to see is vastly different from what a inbound call center agent or enterprise user should see and should call validation data be combined with other forms of calling party identity in a expanded  CNAM (calling party name) like service offering.  In the EU for example they have no experience at all with CNAM.  That has typically been a North Americian service. 

I understand the argument for a binary data display such as green check vs red octonganal stop like visual indicator and there are serious nuances in what type of text should be displayed. We are not there yet.   We are delving into the black arts of UI design here and we are simply going to have to do some experimentation to come up with answers and even then its clear that one size may not fit all.

In any event there is already a thoughtful discussion between the service provider community and some national regulators on what the options are.

..

On 7/19/17, 2:46 PM, "sipcore on behalf of Asveren, Tolga" <[email-masked] on behalf of [email-masked]> wrote:

    
    Thanks,
    Tolga
    
    -----Original Message-----
    From: Henning Schulzrinne [mailto:[email-masked]] 
    Sent: Wednesday, July 19, 2017 2:33 PM
    To: Asveren, Tolga <[email-masked]>; Paul Kyzivat <[email-masked]>; [email-masked]
    Subject: RE: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities

    

    
    Henning
    
    -----Original Message-----
    From: sipcore [mailto:[email-masked]] On Behalf Of Asveren, Tolga
    Sent: Wednesday, July 19, 2017 2:11 PM
    To: Paul Kyzivat <[email-masked]>; [email-masked]
    Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities

    Thanks,
    Tolga

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 20 Jul 2017 17:17:09 +0000

There are four likely models:

* the call type (and spam-quotient) information may be shown to users, but most likely when reviewing voice mail, not a ringing call (where a simple binary indicator is probably more suitable, derived from information in the draft, possibly)
* various end system call handling algorithms, e.g., the semi-automated 'do not disturb' features in Android and iOS, so that, for example, non-personal calls would be directed to voice mail after 10 pm or during meetings.
* PBX and similar corporate systems that filter and manage calls, whether by corporate policy (e.g., to prevent Microsoft "support" calls) or by user preference
* as a call-out to a third-party system - the call information is proxied to a third party system, which then add the call-info labeling to the call

In all cases, the information in the header would seem to be, at most, be indirectly reflected in the appropriate user interface.  But, in my view, you need to provide the end system and UI with a bit more data so that they can do the filtering and UI tailoring. It's easy to turn a spam score into red and green, but you can't set red and green thresholds appropriate to the circumstances if the carrier has already made that decision.

The CNAM information seems complementary to this, although it might use some of the same type labeling. CNAM also seems to require far more originator cooperation (and a caller is unlikely to label itself as "spam"...).

Henning

-----Original Message-----
From: Richard Shockey [mailto:[email-masked]] 
Sent: Thursday, July 20, 2017 12:22 PM
To: Asveren, Tolga <[email-masked]>; Henning Schulzrinne <[email-masked]>; Paul Kyzivat <[email-masked]>; [email-masked]
Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities

..

    
    
    Thanks,
    Tolga
    
    -----Original Message-----
    From: Henning Schulzrinne [mailto:[email-masked]] 
    Sent: Wednesday, July 19, 2017 2:33 PM
    To: Asveren, Tolga <[email-masked]>; Paul Kyzivat <[email-masked]>; [email-masked]
    Subject: RE: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities

    

    
    Henning
    
    -----Original Message-----
    From: sipcore [mailto:[email-masked]] On Behalf Of Asveren, Tolga
    Sent: Wednesday, July 19, 2017 2:11 PM
    To: Paul Kyzivat <[email-masked]>; [email-masked]
    Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities

    Thanks,
    Tolga

    _______________________________________________
    sipcore mailing list
    [email-masked]
    https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_sipcore&d=DwICaQ&c=y0h0omCe0jAUGr4gAQ02Fw&r=FJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=B4eJ1PKmueNhKHee7Uns8SvL4EwRgp-A98tQOLWwL2g&s=06LUWYaIYuqYCl5NSo8ONPBkR7yWFyc-8lxUlVTOyWI&e=

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 20 Jul 2017 18:41:07 +0000

O.K., this sounds good. It really could be good to add a sentence or two about this issue -even if the syntax already defines "spam" as optional"- though.
"Use of spam parameter requires a fine granularity decision about the nature of the call. It may not be possible to easily predict or use in an efficient way for certain networks, call flows, end-points."

Thanks,
Tolga

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

Or

for non-spam.

Henning

-----Original Message-----
From: Asveren, Tolga [mailto:[email-masked]] 
Sent: Wednesday, July 19, 2017 2:46 PM
To: Henning Schulzrinne <[email-masked]>; Paul Kyzivat <[email-masked]>; [email-masked]
Subject: RE: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities

Thanks,
Tolga

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 20 Jul 2017 19:21:32 +0000

It does say explicitly that all parameters are optional, but I will add text about what the absence means ("good enough", basically, since no indicator is 100% correct).

-----Original Message-----
From: Asveren, Tolga [mailto:[email-masked]] 
Sent: Thursday, July 20, 2017 2:41 PM
To: Henning Schulzrinne <[email-masked]>; Paul Kyzivat <[email-masked]>; [email-masked]
Subject: RE: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities

Thanks,
Tolga

---

From: Richard Shockey <[email-masked]>
Date: Thu, 20 Jul 2017 15:33:15 -0400

In line..

On 7/20/17, 1:17 PM, "Henning Schulzrinne" <[email-masked]> wrote:

RS>  That’s what I’ve been thinking.  The binary indicator is most useful during ringing and that is the 2-3 seconds you have when you look at the UA.  Some Data Analytics vendors have indicated there is zero difference in consumer behavior on binary display (good vs bad red vs green) vs granular scoring (0-100) display for instance.  This is really the VERISAT 3GPP parameter for inband SIP usage vs some other out of band transmittal (HTTP) to the UA. 

RS> Agreed but I’m not sure how much UA programming people can actually handle. Of course, we can program pretty much anything we want into the UA at this point.  But some of this may be network or proxy (PBX) based as well. 

    * PBX and similar corporate systems that filter and manage calls, whether by corporate policy (e.g., to prevent Microsoft "support" calls) or by user preference.
    * as a call-out to a third-party system - the call information is proxied to a third party system, which then add the call-info labeling to the call

RS> These may be closely bound.  Its clear at least from some discussions I’ve had with enterprises that they may want to manage this process themselves for various legal and regulatory concerns.  There are clearly early adopter industries. Financial Services, Health Care and Utilities where these techniques come under the general heading of “reputation management” and fraud protection.  There is another use case involving public safety that has been barely touched. 

RS> Sure but this is ultimately a consumer / enterprise decision on who does what to analyze the call.  My guess is most consumers (98%) would want the carrier to deal with it.  That’s what we pay them for and life is too complicated as it is.  Enterprises, especially those that rely on various forms of voice communications for mission critical applications may take a different view.  I suspect many of them do not want to rely on carrier data analytics if they are to be held liable for the consequences.  If we can properly define a limited set of tools then the market will sort out the gory details.  The good news here is that there is a ready market for these solutions if we can define to tool kit correctly.  

RS> Agreed.  “Empower Consumers” as you colleague’s on 12th street would call it.  ( 
    
    Henning
    
    -----Original Message-----
    From: Richard Shockey [mailto:[email-masked]] 
    Sent: Thursday, July 20, 2017 12:22 PM
    To: Asveren, Tolga <[email-masked]>; Henning Schulzrinne <[email-masked]>; Paul Kyzivat <[email-masked]>; [email-masked]
    Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities

    

    ..

        
        
        Thanks,
        Tolga
        
        -----Original Message-----
        From: Henning Schulzrinne [mailto:[email-masked]] 
        Sent: Wednesday, July 19, 2017 2:33 PM
        To: Asveren, Tolga <[email-masked]>; Paul Kyzivat <[email-masked]>; [email-masked]
        Subject: RE: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities

        

        
        Henning
        
        -----Original Message-----
        From: sipcore [mailto:[email-masked]] On Behalf Of Asveren, Tolga
        Sent: Wednesday, July 19, 2017 2:11 PM
        To: Paul Kyzivat <[email-masked]>; [email-masked]
        Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities

        Thanks,
        Tolga

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 Jul 2017 16:12:41 -0400

> RS>  That’s what I’ve been thinking.  The binary indicator is most useful during ringing and that is the 2-3 seconds you have when you look at the UA.  Some Data Analytics vendors have indicated th…

Ring tones could be used to indicate more than a binary choice while 
remaining easy and quick to understand.

> RS> Sure but this is ultimately a consumer / enterprise decision on who does what to analyze the call.  My guess is most consumers (98%) would want the carrier to deal with it.  That’s what we pay them for and life is too complicated as it is.  

Speak for yourself. Admittedly perhaps everyone reading this will fall 
within the 2%. But lots of people are already familiar with configuring 
their ring tones and dialer. It is not at all hard to imagine quite a 
lot of people (at least those < 30 years old) wanting to tweak this stuff.

	Thanks,
	Paul

---

From: Richard Shockey <[email-masked]>
Date: Thu, 20 Jul 2017 17:03:54 -0400

On 7/20/17, 4:12 PM, "sipcore on behalf of Paul Kyzivat" <[email-masked] on behalf of [email-masked]> wrote:

    

RS>  Humm that’s a good point.  It is something to consider especially for those with visual impairments.  “Warning Will Robinson” Seriously its an important consideration.   

RS> Fair enough.  Choice is fine until someone screws up and you cant find the “reset to default” button.  
    
    	Thanks,
    	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 20 Jul 2017 22:18:28 +0000

From: sipcore <[email-masked]> on behalf of Richard Shockey <[email-masked]>

Consider the Android "Do not disturb" model. It's fairly programmable and you can define time-of-day and event rules and then what are "priority" interrupts that are allowed. Currently, there's "calls from..." starred contacts, from anyone, from contacts, none. You could imagine adding "from non-spam callers" or "personal calls", say, based on the Call-Info header information.

This does not require that users write Javascript code and most users will probably just leave the default behavior, but this offers flexibility to the mobile OS vendors to implement interesting behavior.

Henning

---

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

Would this spam indicator really be useful for anything else during ringing? For post-ringing, the "ultimate decision maker" is already in the loop, the enduser himself. He doesn't need the network to tell him whether the call was spam or not (or a survey or etc...), he can decide himself.

And regarding granularity during ringing, would the UI really display something like "There is a 87% chance that this is a robocall" or "There is a 61% chance that this is a survey". IMHO, we really are already in the "information overdose" area.

Thanks,
Tolga

From: sipcore [mailto:[email-masked]] On Behalf Of Henning Schulzrinne
Sent: Thursday, July 20, 2017 6:18 PM
To: Richard Shockey <[email-masked]>; Paul Kyzivat <[email-masked]>; [email-masked]
Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities

From: sipcore <[email-masked]<mailto:[email-masked]>> on behalf of Richard Shockey <[email-masked]<mailto:[email-masked]>>

RS> Fair enough.  Choice is fine until someone screws up and you cant find the "reset to default" button.

Henning

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 21 Jul 2017 11:19:46 +0000

Initially I liked the idea of using "type" as a binary indicator but after thinking a bit more about it:

i- I don't think that would be proper use of "type". It is not meant to indicate probability but, as the name indicates, the type of the call. Overloading its semantics is not a good idea IMHO. So, still using "spam" is the right thing to do if one want to go "binary" AFAICT.
ii- On another node on "type": I really am not sure what use this field would have as far as enduser is concerned. As I indicated in an earlier message, any indication has practical value only during ringing IMHO. Do we really foresee the UI display something related with the "type" -unless it is for a type-value, for which network can assert 100% that is correct, e.g. "government", "emergency-alert"? I would keep type-values restricted to such values.

Thanks,
Tolga

-----Original Message-----
From: Asveren, Tolga [mailto:[email-masked]] 
Sent: Thursday, July 20, 2017 2:41 PM
To: Henning Schulzrinne <[email-masked]>; Paul Kyzivat <[email-masked]>; [email-masked]
Subject: RE: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities

Thanks,
Tolga

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 21 Jul 2017 11:55:13 -0400

On 7/21/17 6:49 AM, Asveren, Tolga wrote:

> And regarding granularity during ringing, would the UI really display 
> something like “There is a 87% chance that this is a robocall” or “There 
> is a 61% chance that this is a survey”. IMHO, we really are already in 
> the “information overdose” area.

That sounds like a really bad UI - I think I would choose a different app.

But my UI might show a green/yellow/red indicator. Or maybe a larger 
spectrum of colors. Or, as I already mentioned, there might be different 
ring tones for various ranges of probability.

The trick is, if the range is from 0-100 then you can carve it up into 
two categories, Henning can carve it up into three, and I can have five 
distinct ranges if I want. If the SP makes a binary choice then we don't 
have those options.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 21 Jul 2017 11:58:58 -0400

On 7/21/17 7:19 AM, Asveren, Tolga wrote:
> As I indicated in an earlier message, any indication has practical value only during ringing IMHO.

Henning already mentioned the idea of displaying it along with 
voicemails. Certainly at that point you can listen to the voicemail and 
decide for yourself. But when your mailbox is full up with junk you are 
likely to want to use this info to help decide which ones to listen to 
and which ones to defer or delete without listening.

	Thanks,
	Paul