Subject: Re: [dispatch] Two new VoIP spam drafts

From: [email-masked] (Dale R. Worley)
Date: Tue, 04 Oct 2016 14:01:00 -0400

Henning Schulzrinne <[email-masked]> writes:
> https://datatracker.ietf.org/doc/draft-schulzrinne-dispatch-status-unwanted/
>
> https://datatracker.ietf.org/doc/draft-schulzrinne-dispatch-callinfo-spam/

1. I like the symbolism of using 666 as a response code, but 6xx codes
are generally a bad idea because they require one UAC to assert a fact
about all the other possible destinations of the INVITE, which the UAC
cannot know.  (See draft-worley-6xx-considered-harmful.)  So it should
be a 4xx response code.

2. draft-schulzrinne-dispatch-callinfo-spam says:

   If the entity
   inserting the header field does not have information it wants to link
   to, it MUST use an empty data URL [RFC2397] as a placeholder, as in
   "data:".  (The Call-Info header field syntax makes the URI itself
   mandatory.)

That's a clever idea, using a data: URI as a null, which we could have
used in some other situations.  But "data:" is not a valid URI, the
syntax shows that it must be "data:,".

3. Since draft-schulzrinne-dispatch-callinfo-spam specifies a manner of
indicating characteristics of a call, it comes to mind that the "type"
category could be signaled using a new series of "alert" URNs:

    urn:alert:type:business
    urn:alert:type:debt-collection
    etc.

But it's hard to place that URN well.  It seems to be the correct choice
to put the spam information in a Call-Info header, but an "alert" URN
won't affect alerting unless it's placed in an Alert-Info header.

Dale

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 4 Oct 2016 19:54:02 +0000

Dale,

thanks for your comments. In this particular case, I disagree with your first argument. The whole point of the "Unwanted" response is exactly that the UAC is making a decision on behalf of the destination number and all associated destinations (UACs). It does want any forking to stop immediately. It never wants to hear from the number again, on any device associated with the destination number. This is meant for single-person/household/office tel URIs as the common use case, but maybe there are cases (some kind of group destination?) we need to carve out where this should not be used.

A 4xx does not seem to have the intended effect. "Unwanted here" is also ambiguous - what is the serving carrier supposed to do with that? "Hey guys, make up your minds - do you want this caller or not?"

Henning

________________________________
From: Dale R. Worley <[email-masked]>
Sent: Tuesday, October 4, 2016 2:01:00 PM
To: Henning Schulzrinne
Cc: [email-masked]
Subject: Re: [dispatch] Two new VoIP spam drafts

   If the entity

    urn:alert:type:business

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 07 Oct 2016 10:18:12 -0400

Henning Schulzrinne <[email-masked]> writes:

> The whole point of the "Unwanted" response is
> exactly that the UAC is making a decision on behalf of the destination
> number and all associated destinations (UACs).

OTOH, my point is that the 6xx response applies to all forks of the
called number, which may not be the destination number.  In fact, the
called UA doesn't *know* the called number.

> It does want any forking to stop immediately. It never wants to hear
> from the number again, on any device associated with the destination
> number. This is meant for single-person/household/office tel URIs as
> the common use case, but maybe there are cases (some kind of group
> destination?) we need to carve out where this should not be used.

There are an infinite number of possibilities.  I expect the commonest
case is for all possible destinations of a call to be under control of
one person or organization, but there's no requirement for that in SIP.

Dale

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 7 Oct 2016 17:22:56 +0000

I think this is a 95/5 problem. In almost all practical -- residential, PBX or mobile, circumstances, the called party can be nearly certain that it is identified by the To header field and that there is no forking to other subscribers (there may be forking to other devices, such as simul-ring, but those can safely be assumed to share the same "opinion" about the call).

Can you provide a practical, deployed example where this is not the case? You seem to have cases in mind that I can't think of.

I agree that this caution should be called out, so maybe you can suggest some suitable text that indicates the applicability. Would some version of "This SHOULD only be used in use cases where each call only reaches a single logical subscriber, such as a single residential subscriber phone number, rather than administratively independent entities?"

________________________________
From: Dale R. Worley <[email-masked]>
Sent: Friday, October 7, 2016 10:18 AM
To: Henning Schulzrinne
Cc: [email-masked]
Subject: Re: [dispatch] Two new VoIP spam drafts

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 7 Oct 2016 16:18:09 -0400

> called UA doesn't *know* the called number.

An interesting point. If my calls are forwarded to a colleague while I 
am on vacation, and he rejects a caller, does that get handled as *my* 
preference?

If the spam filtering is handled by the same intermediary as the one 
handling the forwarding then presumably it can be sorted out. But if the 
filtering is done upstream from where the forwarding is done it may be 
difficult to tell.

	Thanks,
	Paul

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Fri, 7 Oct 2016 20:20:21 +0000

No

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 Oct 7, 2016, at 4:18 PM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:

On 10/7/16 10:18 AM, Dale R. Worley wrote:
Henning Schulzrinne <[email-masked]<mailto:[email-masked]>> writes:

An interesting point. If my calls are forwarded to a colleague while I am on vacation, and he rejects a caller, does that get handled as *my* preference?

If the spam filtering is handled by the same intermediary as the one handling the forwarding then presumably it can be sorted out. But if the filtering is done upstream from where the forwarding is done it may be difficult to tell.

   Thanks,
   Paul

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 7 Oct 2016 20:31:15 +0000

I would argue that, practically speaking, there's not much difference. This is a statistical indicator, so whether this truly speaks for the principal or his/her vacation sub seems only important at the margins. You could also argue that if you don't trust your colleague to recognize spam calls, you may not want him or her to answer calls for you. You may even answer one of the "industry thought leader" survey calls for that person...

Things get slightly trickier if 666 triggers addition to a personal blacklist. Even here, I'd argue that this makes sense. If my colleague is kind enough to answer my calls for the next two weeks, she has every right not to be bothered by the same nuisance caller multiple times. I do run the risk that I won't get out of the next speeding ticket since she didn't contribute to the Police Benevolence Association.

________________________________
From: dispatch <[email-masked]> on behalf of Paul Kyzivat <[email-masked]>
Sent: Friday, October 7, 2016 4:18:09 PM
To: [email-masked]
Subject: Re: [dispatch] Two new VoIP spam drafts

        Thanks,
        Paul

[email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 7 Oct 2016 16:44:41 -0400

Martin,

> No

Your one-word answers aren't helpful! They add nothing but noise to the 
conversation. I have no idea what your "No" means? I figure it could be 
any of the following:

1) No - its not an interesting point. (Why?)

2) No - if my calls are forwarded to a colleague while I am on vacation, 
and he rejects a caller, it does *not* get treated as *my* preference. 
(In which case my later point about filtering being handled upstream of 
forwarding becomes important.)

3) No - if filtering is done upstream from where the forwarding is done 
it *won't* be difficult to tell. (Why not?)

4) No - you don't consider comments from Paul as deserving a thoughtful 
answer.

	Paul

> *Martin C. Dolly*
> Cell: +1.609.903.3360 <tel:+1.609.903.3360>
>
> Email: [email-masked] <mailto:[email-masked]>_
>
>
>
>
>>> Henning Schulzrinne <[email-masked]
>>> <mailto:[email-masked]>> writes:
>>>
>> handling the forwarding then presumably it can be sorted out. But if
>> the filtering is done upstream from where the forwarding is done it
>> may be difficult to tell.
>>
>>    Thanks,
>>    Paul
>>
>>
>>
>> [email-masked] <mailto:[email-masked]>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 7 Oct 2016 16:52:36 -0400

On 10/7/16 4:31 PM, Henning Schulzrinne wrote:
> I would argue that, practically speaking, there's not much difference.
> This is a statistical indicator, so whether this truly speaks for the
> principal or his/her vacation sub seems only important at the margins.
> You could also argue that if you don't trust your colleague to recognize
> spam calls, you may not want him or her to answer calls for you. You may
> even answer one of the "industry thought leader" survey calls for that
> person...
>
>
> Things get slightly trickier if 666 triggers addition to a personal
> blacklist. Even here, I'd argue that this makes sense. If my colleague
> is kind enough to answer my calls for the next two weeks, she has every
> right not to be bothered by the same nuisance caller multiple times. I
> do run the risk that I won't get out of the next speeding ticket since
> she didn't contribute to the Police Benevolence Association.

This depends a lot on how these responses get used. There is a 
significant difference between using this to get a statistical measure 
from the population as a whole, and building a personal black-list. I 
was thinking it might be used for both.

What if the call to me was from my colleague's abusive spouse? I may 
still have a need to receive calls from that person even though my 
colleague does not.

And I don't know if we can assume a forwardee will know that the 
incoming call has been forwarded.

	Thanks,
	Paul

> ------------------------------------------------------------------------
> *From:* dispatch <[email-masked]> on behalf of Paul Kyzivat
> <[email-masked]>
> *Sent:* Friday, October 7, 2016 4:18:09 PM
> *To:* [email-masked]
> *Subject:* Re: [dispatch] Two new VoIP spam drafts
>

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Fri, 7 Oct 2016 20:55:52 +0000

# goes on his blacklist if he has said service

Martin C. Dolly

On Oct 7, 2016, at 4:52 PM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:

This depends a lot on how these responses get used. There is a significant difference between using this to get a statistical measure from the population as a whole, and building a personal black-list. I was thinking it might be used for both.

What if the call to me was from my colleague's abusive spouse? I may still have a need to receive calls from that person even though my colleague does not.

And I don't know if we can assume a forwardee will know that the incoming call has been forwarded.

   Thanks,
   Paul

------------------------------------------------------------------------
*From:* dispatch <[email-masked]<mailto:[email-masked]>> on behalf of Paul Kyzivat
<[email-masked]<mailto:[email-masked]>>
*Sent:* Friday, October 7, 2016 4:18:09 PM
*To:* [email-masked]<mailto:[email-masked]>
*Subject:* Re: [dispatch] Two new VoIP spam drafts

       Thanks,
       Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 7 Oct 2016 21:05:18 +0000

If you don't want your colleague to spam-mark your calls, you may want to tell her. Also, as a local implementation choice, the receiving UA may disable the "spam" button if the call (To) is not originally for that destination.

Note that the same model works for email, and the world has lived. If I forward my email to a colleague, the spam button she uses may well trigger the same (local and/or crowd-sourced) blacklisting.

Users seem to understand spam buttons, recognizing that they occasionally lead to mistaken markings and some manual clean-up, such as the postmaster whitelisting or removing blacklisted addresses.

I suspect there's only so much we can do for user-facing behavior. We seem to agree that documenting these cases so that developers can make situationally-appropriate choices seems like a good idea.

________________________________
From: Paul Kyzivat <[email-masked]>
Sent: Friday, October 7, 2016 4:52:36 PM
To: Henning Schulzrinne; [email-masked]
Subject: Re: [dispatch] Two new VoIP spam drafts

        Thanks,
        Paul

---

From: Richard Shockey <[email-masked]>
Date: Fri, 07 Oct 2016 17:36:42 -0400

+1

Though I have endless issues with blacklisting for endless reasons.  You can blacklist … but then how do you get off the black list if you have reason to believe you improperly put on in the first place. That has been the bane of SPAMHOUS and the rest of those <fill in the blank> from the beginning which is why I’ve totally opposed trying to simply say “well we solved this in DANE or DKIM so problem solved.”  This is telephony not email. 

As a general principal Henning is right ..there is only so much we can do. We can anticipate specific use cases but until we get some reasonable operational experience we can’t refine the process.    

— 

Richard Shockey

Shockey Consulting LLC

Chairman of the Board SIP Forum

www.shockey.us

www.sipforum.org

richard<at>shockey.us

Skype-Linkedin-Facebook rshockey101

PSTN +1 703-593-2683

From: dispatch <[email-masked]> on behalf of Henning Schulzrinne <[email-masked]>
Date: Friday, October 7, 2016 at 5:05 PM
To: Paul Kyzivat <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [dispatch] Two new VoIP spam drafts

        Thanks,
        Paul

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

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 8 Oct 2016 12:17:40 -0400

On 10/7/16 5:36 PM, Richard Shockey wrote:
> +1
>
>
>
> Though I have endless issues with blacklisting for endless reasons.  You
> can blacklist … but then how do you get off the black list if you have
> reason to believe you improperly put on in the first place. That has
> been the bane of SPAMHOUS and the rest of those <fill in the blank> from
> the beginning which is why I’ve totally opposed trying to simply say
> “well we solved this in DANE or DKIM so problem solved.”  This is
> telephony not email.
>
>
>
> As a general principal Henning is right ..there is only so much we can
> do. We can anticipate specific use cases but until we get some
> reasonable operational experience we can’t refine the process.

I agree with all of that. But it says we are defining a code without 
defining precisely what it means - that we are leaving it to the 
implementations and UI designers to decide what it means. So the 
definition of the meaning of the code should be correspondingly vague.

	Thanks,
	Paul

> *From: *dispatch <[email-masked]> on behalf of Henning
> Schulzrinne <[email-masked]>
> *Date: *Friday, October 7, 2016 at 5:05 PM
> *To: *Paul Kyzivat <[email-masked]>, "[email-masked]"
> <[email-masked]>
> *Subject: *Re: [dispatch] Two new VoIP spam drafts
>
>
>
> If you don't want your colleague to spam-mark your calls, you may want
> to tell her. Also, as a local implementation choice, the receiving UA
> may disable the "spam" button if the call (To) is not originally for
> that destination.
>
>
>
> Note that the same model works for email, and the world has lived. If I
> forward my email to a colleague, the spam button she uses may well
> trigger the same (local and/or crowd-sourced) blacklisting.
>
>
>
> Users seem to understand spam buttons, recognizing that they
> occasionally lead to mistaken markings and some manual clean-up, such as
> the postmaster whitelisting or removing blacklisted addresses.
>
>
>
> I suspect there's only so much we can do for user-facing behavior. We
> seem to agree that documenting these cases so that developers can make
> situationally-appropriate choices seems like a good idea.
>
> *From:*Paul Kyzivat <[email-masked]>
> *Sent:* Friday, October 7, 2016 4:52:36 PM
> *To:* Henning Schulzrinne; [email-masked]
> _______________________________________________ dispatch mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Sat, 8 Oct 2016 16:32:50 +0000

Not so. SP records code and initiates procedures (reporting, blacklist, trace back)

Martin C. Dolly

On Oct 8, 2016, at 12:17 PM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:

I agree with all of that. But it says we are defining a code without defining precisely what it means - that we are leaving it to the implementations and UI designers to decide what it means. So the definition of the meaning of the code should be correspondingly vague.

   Thanks,
   Paul

—

Richard Shockey

Shockey Consulting LLC

www.shockey.us<http://www.shockey.us>

www.sipforum.org<http://www.sipforum.org>

richard<at>shockey.us<http://shockey.us>

PSTN +1 703-593-2683

*From: *dispatch <[email-masked]<mailto:[email-masked]>> on behalf of Henning
Schulzrinne <[email-masked]<mailto:[email-masked]>>
*Date: *Friday, October 7, 2016 at 5:05 PM
*To: *Paul Kyzivat <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>"
<[email-masked]<mailto:[email-masked]>>
*Subject: *Re: [dispatch] Two new VoIP spam drafts

*From:*Paul Kyzivat <[email-masked]<mailto:[email-masked]>>
*Sent:* Friday, October 7, 2016 4:52:36 PM
*To:* Henning Schulzrinne; [email-masked]<mailto:[email-masked]>
*Subject:* Re: [dispatch] Two new VoIP spam drafts

       Thanks,
       Paul

       Thanks,
       Paul

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

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 8 Oct 2016 16:20:58 -0400

>> definition of the meaning of the code should be correspondingly vague.

When I said *we* I meant the people who will collectively be deciding to 
approve a new response code.

Then there are SPs who will be implementing services in the network 
based on receiving this code, and device makers who will be designing UI 
through which users can cause this code to be signaled.

It sounds like there may be at least two different services that SPs 
will implement based on the new code: (1) a statistical determination of 
generally bad actors, and (2) a private blacklist for individual 
subscribers.

And in addition to SPs, others (e.g. PBX vendors) may also be 
implementing (2).

In addition to the SPs, there may also be others (e.g. PBX vendors) 
implementing private blacklists, either for their system as a whole or 
for each of their individual users, based on the same codes.

Who, in this collection of participants should define the precise 
meaning of the code?

It would be unfortunate if pressing the same button on the phone means 
one thing at work, something different on my ATT phone, and something 
different from that after I port my phone to Verizon.

If the intent is that the FCC and the US providers decide the meaning 
for the US, then the definition should reflect that that is what it is.

	Thanks,
	Paul

---

From: "Asveren, Tolga" <[email-masked]>
Date: Sun, 9 Oct 2016 10:03:33 +0000

i- I don't think it is such a horrible thing if "spam button" has different semantics for different networks. Actually, for each network, it would be a *different* button. I don't think we should assume that we are in the bad old days of POTS with a *single UI*. Each UE/SP pair may provide a different UI experience, and this wouldn't be limited just to the spam button. IMHO this is not an issue, users are already familiar with this concept and I don't think it is something bothering them.

ii- I think, like many other things in practice, what a retargeting/forking element does with 666 would be mainly determined by "local policy". It could be a good idea to add a paragraph discussing this aspect -with some examples- but I am not sure mandating a particular set of tightly defined semantics is the right approach. I wouldn't think so.

Thanks,
Tolga

> -----Original Message-----
> From: dispatch [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Saturday, October 08, 2016 4:21 PM
> To: DOLLY, MARTIN C <[email-masked]>
> Cc: [email-masked]
> Then there are SPs who will be implementing services in the network based
> on receiving this code, and device makers who will be designing UI through
> which users can cause this code to be signaled.
> 
> It sounds like there may be at least two different services that SPs will
> implement based on the new code: (1) a statistical determination of
> generally bad actors, and (2) a private blacklist for individual subscribers.
> 
> And in addition to SPs, others (e.g. PBX vendors) may also be implementing
> (2).
> 
> implementing private blacklists, either for their system as a whole or for each
> of their individual users, based on the same codes.
> 
> Who, in this collection of participants should define the precise meaning of
> the code?
> 
> If the intent is that the FCC and the US providers decide the meaning for the
> US, then the definition should reflect that that is what it is.
> 
> 	Thanks,
> 	Paul
>

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Mon, 10 Oct 2016 14:38:10 +0000

I know that this is not handed by IETF documents, but at least for all definitions of a diversion type service I know, then the diverted to user becomes the destination party and all supplementary services and so on associated with the new destination user become the ones that are applicable, not the ones associated with the diverting user (there are a few minor exceptions to this in terms of passing on identities).

Therefore I would expect this to follow through that any spamming user that gets diverted goes on the blacklist of the diverted to user rather the blacklist of the diverting user.

I believe this corresponds to what Martin is saying.

Keith

From: dispatch [mailto:[email-masked]] On Behalf Of DOLLY, MARTIN C
Sent: 07 October 2016 21:56
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [dispatch] Two new VoIP spam drafts

   Thanks,
   Paul

       Thanks,
       Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 Oct 2016 11:09:11 -0400

> i- I don't think it is such a horrible thing if "spam button" has different semantics for different networks. Actually, for each network, it would be a *different* button. I don't think we should a…

Perhaps that will happen in the spirit of "let 1000 flowers bloom".
If we don't know what will work best then some experimentation can be a 
good thing.

But in that case it needs to be handled carefully to avoid confusing end 
users. That can be handled by having a different UI when the semantics 
differ.

But if this is per-SP, while phone UI is not per-SP, then this could 
become a problem. (E.g., the iPhone UI stays pretty much the same 
regardless of what SP you use.)

But *we* (IETF) don't control that part, though we need to take account 
of it. What we do control is the signaling. I find it problematic if 
these UIs all end up signaling the same code point, and then SPs assume 
they mean different things and take different actions.

If we want to let a 1000 flowers bloom then we ought to provide a 
corresponding range of code points to represent these nuances. (That 
*doesn't* mean that the UI will inflict a range of choices on the user 
each time. It might be that each UI only offers one option. Or maybe 
there is a choice between a simple option and "advanced" that brings up 
a more complex interface to describe how you feel about the call.)

I have been thinking more about this, trying to relate it to what has 
been learned about email spam. ISTM that the analogy is not very good:

When you mark an email as spam, the body of that email is available to 
analyze. It can be put in a DB, and then the collection can be analyzed 
for similarities, and those can then be refined into a filter that 
distinguishes spam from non-spam.

When you mark a phone call as spam, there is much less to work with. If 
it was marked *before* the call was answered, then all 	callee had to go 
on to mark it was the information presented to the callee by the phone 
UI. (And this is a lot less than was present in the signaling.) If all 
that comes back to the SP is a single code point (666) meaning "spam", 
then the SP must guess what it was in the signaling that provoked that 
response.

If the callee rejects the call as "spam" *after* answering the call, 
then (s)he had additional information to go on - the content of the 
media.  But the SP doesn't know what that content was, and also doesn't 
know what about that content was objectionable. The only additional 
information the SP has is that the callee didn't reject it sooner. That 
might or might not be significant. If it was the content that was 
objectionable, then it may or may not correlate with with information in 
the signaling.

Bottom line - ISTM there ought to be a mechanism that allows the UI (on 
behalf of the callee) to choose from a variety of reasons for 
classifying the calls rejected as spam. And that menu ought to be 
extensible. This doesn't lend itself to being represented as a response 
code. This could possibly be handled via a new "protocol" value for the 
Reason header, thus allowing a whole range of new values. Then every SP 
or every UI developer could potentially register a new code that lines 
up with their UI or their algorithm. (Again, I am not suggesting that 
every UI offer every possibility to the callee.)

> ii- I think, like many other things in practice, what a retargeting/forking element does with 666 would be mainly determined by "local policy". It could be a good idea to add a paragraph discussing…

Yes. The obvious situation to me is when a PBX or IVR is present. As 
long as it is made clear to the deploying organization that they need to 
consider this and screen spam indications passed back to the SP then it 
should be ok. OR, the SPs could provision different customer connections 
regarding whether to act on spam indications or not.

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 10 Oct 2016 11:30:32 -0400

Henning Schulzrinne <[email-masked]> writes:
> Can you provide a practical, deployed example where this is not the
> case? You seem to have cases in mind that I can't think of.

People seem to think that it is common to forward a residential phone to
a different residential phone.  The potential complexities of how the
call reached the destination were the motivation for the creation of
History-Info.  The RFCs for History-Info give various examples.

Dale

---

From: Michael Hammer <[email-masked]>
Date: Mon, 10 Oct 2016 16:20:07 +0000

I agree with the idea that the policy on what you do with the call 
should be left to the respective owners:  SP, PBX, end-user.
Those are features that should have a range of possibilities.

I agree that the semantic associated with the code should be explicit, but
not necessarily precise.
"Spam" or "Unwanted call" may be sufficient.  UI developers can follow-up
with the 1000 whys.
But, it might be wise to walk before running wild with this or you risk
confusing users.
KISS may be sufficient to start with.

________________________________
Michael Hammer
[email-masked]
+1 408 202 9291

© 2016 Yaana Technologies, LLC. All Rights Reserved. Email confidentiality
notice. This message is private and confidential. If you have received this
message in error, please notify us and remove it from your system.

-----Original Message-----
From: dispatch [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Monday, October 10, 2016 11:09 AM
To: Asveren, Tolga <[email-masked]>; DOLLY, MARTIN C <[email-masked]>
Cc: [email-masked]
Subject: Re: [dispatch] Two new VoIP spam drafts

On 10/9/16 6:03 AM, Asveren, Tolga wrote:
> i- I don't think it is such a horrible thing if "spam button" has
different semantics for different networks. Actually, for each network, it
would be a *different* button. I don't think we should assume that we are in
the bad old days of POTS with a *single UI*. Each UE/SP pair may provide a
different UI experience, and this wouldn't be limited just to the spam
button. IMHO this is not an issue, users are already familiar with this
concept and I don't think it is something bothering them.

Perhaps that will happen in the spirit of "let 1000 flowers bloom".
If we don't know what will work best then some experimentation can be a good
thing.

But if this is per-SP, while phone UI is not per-SP, then this could become
a problem. (E.g., the iPhone UI stays pretty much the same regardless of
what SP you use.)

But *we* (IETF) don't control that part, though we need to take account of
it. What we do control is the signaling. I find it problematic if these UIs
all end up signaling the same code point, and then SPs assume they mean
different things and take different actions.

If we want to let a 1000 flowers bloom then we ought to provide a
corresponding range of code points to represent these nuances. (That
*doesn't* mean that the UI will inflict a range of choices on the user each
time. It might be that each UI only offers one option. Or maybe there is a
choice between a simple option and "advanced" that brings up a more complex
interface to describe how you feel about the call.)

I have been thinking more about this, trying to relate it to what has been
learned about email spam. ISTM that the analogy is not very good:

When you mark an email as spam, the body of that email is available to
analyze. It can be put in a DB, and then the collection can be analyzed for
similarities, and those can then be refined into a filter that distinguishes
spam from non-spam.

When you mark a phone call as spam, there is much less to work with. If 
it was marked *before* the call was answered, then all 	callee had to go 
on to mark it was the information presented to the callee by the phone UI.
(And this is a lot less than was present in the signaling.) If all that
comes back to the SP is a single code point (666) meaning "spam", then the
SP must guess what it was in the signaling that provoked that response.

If the callee rejects the call as "spam" *after* answering the call, then
(s)he had additional information to go on - the content of the media.  But
the SP doesn't know what that content was, and also doesn't know what about
that content was objectionable. The only additional information the SP has
is that the callee didn't reject it sooner. That might or might not be
significant. If it was the content that was objectionable, then it may or
may not correlate with with information in the signaling.

Bottom line - ISTM there ought to be a mechanism that allows the UI (on
behalf of the callee) to choose from a variety of reasons for classifying
the calls rejected as spam. And that menu ought to be extensible. This
doesn't lend itself to being represented as a response code. This could
possibly be handled via a new "protocol" value for the Reason header, thus
allowing a whole range of new values. Then every SP or every UI developer
could potentially register a new code that lines up with their UI or their
algorithm. (Again, I am not suggesting that every UI offer every possibility
to the callee.)

> ii- I think, like many other things in practice, what a
retargeting/forking element does with 666 would be mainly determined by
"local policy". It could be a good idea to add a paragraph discussing this
aspect -with some examples- but I am not sure mandating a particular set of
tightly defined semantics is the right approach. I wouldn't think so.

Yes. The obvious situation to me is when a PBX or IVR is present. As long as
it is made clear to the deploying organization that they need to consider
this and screen spam indications passed back to the SP then it should be ok.
OR, the SPs could provision different customer connections regarding whether
to act on spam indications or not.

	Thanks,
	Paul

>>>> I agree with all of that. But it says we are defining a code 
>>>> without defining precisely what it means - that we are leaving it 
>>>> to the implementations and UI designers to decide what it means. So 
>>>> the definition of the meaning of the code should be correspondingly
vague.
>>
>> When I said *we* I meant the people who will collectively be deciding 
>> to approve a new response code.
>>
>> based on receiving this code, and device makers who will be designing 
>> UI through which users can cause this code to be signaled.
>>
>> will implement based on the new code: (1) a statistical determination 
>> of generally bad actors, and (2) a private blacklist for individual
subscribers.
>> implementing private blacklists, either for their system as a whole 
>> or for each of their individual users, based on the same codes.
>>
>> It would be unfortunate if pressing the same button on the phone 
>> means one thing at work, something different on my ATT phone, and 
>> something different from that after I port my phone to Verizon.
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 Oct 2016 12:54:30 -0400

> KISS may be sufficient to start with.

I agree. But it is worth recognizing the limited nature of the data 
available to work with, and avoid drawing conclusions that cannot be 
supported by that data. If you want to make finer grained decisions you 
need finer grained data to work with.

For instance, the callee may reject the call based on the caller name 
presented, or based on the calling number presented. The calling name 
may or may not be presented to the callee, and if present it may be 
sourced in different ways. (E.g., from the display name of From, or 
P-A-ID, or from the user's local address book.)

Without knowledge of this, the SP may blame the call on something the 
callee didn't see, and that in fact doesn't correlate. So it would be 
helpful to indicate to the SP in some way what it was that was presented 
to the callee, or what the callee was objecting to.

	Thanks,
	Paul

---

From: Brett Tate <[email-masked]>
Date: Mon, 10 Oct 2016 13:48:27 -0400

> > Can you provide a practical, deployed example
> > where this is not the case? You seem to have
> > cases in mind that I can't think of.
>
> People seem to think that it is common to forward
> a residential phone to a different residential
> phone.  The potential complexities of how the call
> reached the destination were the motivation for
> the creation of History-Info. The RFCs for
> History-Info give various examples.

I agree that call services such as those discussed within RFC 7131, RFC
5359, and RFC 3725 should be considered when specifying the solution.

There is also potentially a security concern associated with declaring
unwanted calls.  For instance, students may declare calls from teachers as
unwanted hoping that subsequent calls from teacher to parent are blocked.
However, I'm not sure if worth adding to the Security Consideration
section.

Because of the mandated behavior within RFC 3261 concerning 6xx, I also
agree that the use of 666 instead of a 4xx might not be desirable.  If
there is a need for a 6xx value, it might also be desirable to define a
similar 4xx value (for example see 600/486 comparisons and 606/488
comparisons).

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 10 Oct 2016 18:17:20 +0000

Two quick notes:

(1) In all the cases mentioned so far, the forwarded-to party is authorized by the forwarder to handle the call and is typically "administratively" the same (same family, colleague within same company, colleague who took over your job). Except for movie plot scenarios involving romantic rivalries between work colleagues, I'm having a hard time finding one where the forwarder would not be delighted to have fewer robocalls and would not trust the forwarded-to party to flag such calls.

(2) There is one additional case, but it actually needs the 6xx code: Nomorobo uses simultaneous ringing to filter call. For unknown numbers, it can do a CAPTCHA test ("Please enter 77 if you are a human"). The simul-ring costs money, so combining a third-party filter with a carrier subscriber-blacklist might offer a convenient way to combine consumer choice with efficiency. They would likely return a 666 if done via SIP.

(3) Today, every robocaller is supposed to honor your personal opt-out request, whether they are legally entitled to call you or not. (For example, if a charity calls your US landline, you can still ask them to never call you again, and they are obligated to honor that request.)

If you forward your calls, the forwarded-to party can do exactly that and nobody is going to ask you for your social security number. Thus, this "problem" already exists today, but I admit that nobody in the real world has raised this as a concern in any of the TCPA (legal robocall) proceedings that I'm aware of.

(4) People will indeed accidentally or maliciously mark email or calls as spam. Smart but delinquent kids can already put teachers on the 10-number SCR list that many landline services support. This only requires a *-code, no authentication.

For this and other reasons, I do think that it is useful for people to have the ability to see their personal blacklist and change their mind, at least for numbers that are not known spammers. But that's likely a web page or app, not a SIP request.

(5) I'm happy to add 466 to the draft, but admit that I don't know how this would work differently in practice, except possibly in the forking case, and in that case, I'm having a hard time thinking of common real-world scenarios where one party wants to mark the call unwanted, and another wants to pick up. Clearly, we don't want two spam buttons, as users won't understand the difference.

I realize it's fun to discuss corner cases, but maybe we should learn from the email world where just about every email client and consumer email service has this function, without a 20-page description.

Thus, I think it would be helpful to focus on consumer scenarios where any of these issues matters, not just on protocol behavior.

Henning

________________________________
From: dispatch <[email-masked]> on behalf of Brett Tate <[email-masked]>
Sent: Monday, October 10, 2016 1:48:27 PM
To: [email-masked]
Subject: Re: [dispatch] Two new VoIP spam drafts

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 12 Oct 2016 13:59:37 +0000

Overall, I am in favor of keeping the utility/scope limited to "spam". Just to list a few points along those lines:

i- "666" would indicate that the user considers the call as spam/robocall/annoyance; bottomline being that the user would prefer not to receive calls originating from the same identity.
ii- "666" is not intended to be used for the user to blacklist his mother-in-law. That -already- could be done by other means.
iii- "666" does not automatically blacklists the number/originating identity. It is an input for a spam-blocker service, which possibly can be provided by a SP. It also would be an input for a centralized robocall/spam logic, which possibly is used by multiple SPs and maybe administrated by a national authority.
iv- Actual blacklisting rules/service is something to be decided/provided by the SP. This, for example, may include other components like a web-interface accessible by users. SP may also provide "likely to be spam" (and similar) indicators for calls depending on existing analysis.
v- Consider the above points, I think a 6xx response is the right choice and no 4xx response needs to be added/used.
vi- SP/Central Authority may perform further analysis for a call, which has been rejected with "666", e.g. based on CDRs, logs, existing peering relationships etc...

Thanks,
Tolga

> From: Paul Kyzivat [mailto:[email-masked]]
> > i- I don't think it is such a horrible thing if "spam button" has different
> semantics for different networks. Actually, for each network, it would be a
> *different* button. I don't think we should assume that we are in the bad
> old days of POTS with a *single UI*. Each UE/SP pair may provide a different
> UI experience, and this wouldn't be limited just to the spam button. IMHO
> this is not an issue, users are already familiar with this concept and I don't
> think it is something bothering them.
> 
> But in that case it needs to be handled carefully to avoid confusing end users.
> That can be handled by having a different UI when the semantics differ.
> 
> But if this is per-SP, while phone UI is not per-SP, then this could become a
> problem. (E.g., the iPhone UI stays pretty much the same regardless of what
> SP you use.)
> 
> But *we* (IETF) don't control that part, though we need to take account of it.
> What we do control is the signaling. I find it problematic if these UIs all end up
> signaling the same code point, and then SPs assume they mean different
> things and take different actions.
> 
> choice between a simple option and "advanced" that brings up a more
> complex interface to describe how you feel about the call.)
> 
> similarities, and those can then be refined into a filter that distinguishes spam
> from non-spam.
> 
> (And this is a lot less than was present in the signaling.) If all that comes back
> to the SP is a single code point (666) meaning "spam", then the SP must
> guess what it was in the signaling that provoked that response.
> 
> If the callee rejects the call as "spam" *after* answering the call, then (s)he
> had additional information to go on - the content of the media.  But the SP
> doesn't know what that content was, and also doesn't know what about that
> content was objectionable. The only additional information the SP has is that
> the callee didn't reject it sooner. That might or might not be significant. If it
> was the content that was objectionable, then it may or may not correlate
> with with information in the signaling.
> 
> behalf of the callee) to choose from a variety of reasons for classifying the
> calls rejected as spam. And that menu ought to be extensible. This doesn't
> lend itself to being represented as a response code. This could possibly be
> handled via a new "protocol" value for the Reason header, thus allowing a
> whole range of new values. Then every SP or every UI developer could
> potentially register a new code that lines up with their UI or their algorithm.
> (Again, I am not suggesting that every UI offer every possibility to the callee.)
> 
> > ii- I think, like many other things in practice, what a retargeting/forking
> element does with 666 would be mainly determined by "local policy". It could
> be a good idea to add a paragraph discussing this aspect -with some
> examples- but I am not sure mandating a particular set of tightly defined
> semantics is the right approach. I wouldn't think so.
> 
> Yes. The obvious situation to me is when a PBX or IVR is present. As long as it
> is made clear to the deploying organization that they need to consider this
> and screen spam indications passed back to the SP then it should be ok. OR,
> the SPs could provision different customer connections regarding whether to
> act on spam indications or not.
> 
> 	Thanks,
> 	Paul
> 
> > Thanks,
> > Tolga
> >

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Wed, 12 Oct 2016 14:58:44 +0000

+1, I agree with your summary

Martin C. Dolly

On Oct 12, 2016, at 9:59 AM, Asveren, Tolga <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,
Tolga

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Monday, October 10, 2016 11:09 AM
To: Asveren, Tolga <[email-masked]<mailto:[email-masked]>>; DOLLY, MARTIN C
<[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [dispatch] Two new VoIP spam drafts

it was marked *before* the call was answered, then all    callee had to
go

   Thanks,
   Paul

Thanks,
Tolga

-----Original Message-----
From: dispatch [mailto:[email-masked]] On Behalf Of Paul
Kyzivat
Sent: Saturday, October 08, 2016 4:21 PM
To: DOLLY, MARTIN C <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [dispatch] Two new VoIP spam drafts

On 10/8/16 12:32 PM, DOLLY, MARTIN C wrote:
Not so. SP records code and initiates procedures (reporting,
blacklist, trace back)

On Oct 8, 2016, at 12:17 PM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]>> wrote:

   Thanks,
   Paul

---

From: Ranjit Avasarala <[email-masked]>
Date: Wed, 12 Oct 2016 13:44:26 -0500

Agree with your summary.

Regards
Ranjit

On Wed, Oct 12, 2016 at 8:59 AM, Asveren, Tolga <[email-masked]>
wrote:

> Overall, I am in favor of keeping the utility/scope limited to "spam".
> Just to list a few points along those lines:
>
> i- "666" would indicate that the user considers the call as
> spam/robocall/annoyance; bottomline being that the user would prefer not to
> receive calls originating from the same identity.
> ii- "666" is not intended to be used for the user to blacklist his
> mother-in-law. That -already- could be done by other means.
> iii- "666" does not automatically blacklists the number/originating
> identity. It is an input for a spam-blocker service, which possibly can be
> provided by a SP. It also would be an input for a centralized robocall/spam
> logic, which possibly is used by multiple SPs and maybe administrated by a
> national authority.
> iv- Actual blacklisting rules/service is something to be decided/provided
> by the SP. This, for example, may include other components like a
> web-interface accessible by users. SP may also provide "likely to be spam"
> (and similar) indicators for calls depending on existing analysis.
> v- Consider the above points, I think a 6xx response is the right choice
> and no 4xx response needs to be added/used.
> vi- SP/Central Authority may perform further analysis for a call, which
> has been rejected with "666", e.g. based on CDRs, logs, existing peering
> relationships etc...
>
>
> Thanks,
> Tolga
>
> different
> users.
> become a
> of it.
> each
> been
> for
> UI.
> comes back
> then (s)he
> classifying the
> retargeting/forking
> long as it

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 12 Oct 2016 15:17:32 -0400

> i- "666" would indicate that the user considers the call as spam/robocall/annoyance; bottomline being that the user would prefer not to receive calls originating from the same identity.

While this seems reasonable, how will it work in practice? IOW, when 
will I know to use it?

If I use it before I answer the call, then on what basis am I doing so? 
Is it because I recognize the number? Or is it based on the 
classification assigned by the provider that has been displayed to me?

Will I have an option to use it after I have answered the call? (As an 
alternative to normal hangup.) If so, and if I do so then based on the 
content of the call, is the meaning "would prefer not to receive calls 
originating from the same identity"? I suspect it is really more "would 
prefer not to receive calls of this type", regardless of the callerid. 
(Especially when spam often comes from forged IDs.)

These are two different semantics. Perhaps they can share the same code, 
since they can be distinguished because they are signaled in different 
ways. But it would be cleaner if they were different codes.

> iv- Actual blacklisting rules/service is something to be decided/provided by the SP. This, for example, may include other components like a web-interface accessible by users. SP may also provide "l…

I agree these seem like wise policies.

> v- Consider the above points, I think a 6xx response is the right choice and no 4xx response needs to be added/used.

I'm neutral on this.

> vi- SP/Central Authority may perform further analysis for a call, which has been rejected with "666", e.g. based on CDRs, logs, existing peering relationships etc...

And statistics.

If the same calling number has been flagged by many users *after* they 
have answered the call, then we can infer that there is a consistent 
behavior of bad behavior from this ID. That is worth investigating.

If the same number has been flagged by many users *before* they have 
answered the call, but not corroborated by others flagging it after 
answering, then the situation is unclear. Perhaps this number carries a 
calling name that leads people to reject it? Or perhaps it is a number 
that is special enough to be recognized by a lot of people. I think this 
would need to be investigated carefully to understand what is going on.

	Thanks,
	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 12 Oct 2016 19:34:10 +0000

There are two scenarios, as you state:

* Pre-call: For example, the Call-Info header in my other draft or CNAM ("Cardholder Serv") lead the called party to hit the "spam" button before picking up. This yields a 666 response to the INVITE.

* Mid-call: The called party picks up, listens for 10 seconds, decides they don't need "Microsoft" technical support, and hits the same spam button.  Signaled via BYE with Reason 666.

Just like for email spam, the effect is two-fold, as noted:

(1) I don't want this particular caller to reach me again.
(2) Increment the bad reputation score for the caller.

I don't see this response affecting a whole category of calls. For example, I may decide that I really don't like the Police Benevolence Association call I just received, but that does not necessarily mean that I'd like to block the American Heart Association. I think category-based blocking is going to be set up via a more sophisticated web mechanism that allows finer grained controls ("No charities after 6 pm; only charities with a Charity Navigator rating of A"). Same for political calls - I may want to receive the town hall calls from the politician I like and never again hear from the one I don't.

Spoofing obviously makes call blocking of any sort more problematic, but much spoofing is from numbers that would never call me. For example, blocking the "IRS" doesn't prevent the real IRS from calling me - they don't use the 800# (800-TAX-1040) for outbound calls.

For now, many robocallers don't spoof since they want you to call back, given that many people let unknown callers go to voicemail.

But we've had versions of this discussion in STIR for several years.

Henning

-----Original Message-----
From: dispatch [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Wednesday, October 12, 2016 3:18 PM
To: Asveren, Tolga <[email-masked]>
Cc: [email-masked]
Subject: Re: [dispatch] Two new VoIP spam drafts

> i- "666" would indicate that the user considers the call as spam/robocall/annoyance; bottomline being that the user would prefer not to receive calls originating from the same identity.

While this seems reasonable, how will it work in practice? IOW, when will I know to use it?

If I use it before I answer the call, then on what basis am I doing so? 
Is it because I recognize the number? Or is it based on the classification assigned by the provider that has been displayed to me?

Will I have an option to use it after I have answered the call? (As an alternative to normal hangup.) If so, and if I do so then based on the content of the call, is the meaning "would prefer not to receive calls originating from the same identity"? I suspect it is really more "would prefer not to receive calls of this type", regardless of the callerid. 
(Especially when spam often comes from forged IDs.)

These are two different semantics. Perhaps they can share the same code, since they can be distinguished because they are signaled in different ways. But it would be cleaner if they were different codes.

I'm neutral on this.

And statistics.

If the same calling number has been flagged by many users *after* they have answered the call, then we can infer that there is a consistent behavior of bad behavior from this ID. That is worth investigating.

If the same number has been flagged by many users *before* they have answered the call, but not corroborated by others flagging it after answering, then the situation is unclear. Perhaps this number carries a calling name that leads people to reject it? Or perhaps it is a number that is special enough to be recognized by a lot of people. I think this would need to be investigated carefully to understand what is going on.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 12 Oct 2016 16:00:31 -0400

Henning,

I mostly agree, with some qualifications, inline.

> (2) Increment the bad reputation score for the caller.

Trying to use the same signal to trigger both of these effects presents 
some issues. And I think they differ for Pre-call and mid-call?

(1) seems appropriate for pre-call. It is clear that I am making a 
judgement based on the identity of the caller. Not so clear for 
mid-call. I definitely don't like the content, but that may or may not 
correlate to the caller identity. Risky to block the caller based on 
just this.

(2) This action might be appropriate for both pre-call and mid-call, but 
the two types should probably be tallied separately and evaluated 
differently. For mid-call I am objecting to the content and the tally is 
used to see if the number has a history of bad content. For pre-call we 
really don't know what the callee is objecting to. Still worth tracking, 
but not as strong a measure.

Of course we aren't standardizing this behavior, so discussing it is 
just for context.

My bottom line here is just that it is hard to characterize the meaning 
of the code in a phrase. So I suggest using something quite vague, like 
"Objectionable" without qualification as to whether it is the calling 
id, calling name, content, or whatever that it applies to. The text 
description can go into more detail. But ultimately the meaning will be 
determined by others so we should be vague enough to cover whatever they 
decide to do.

	Thanks,
	Paul

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Thu, 13 Oct 2016 12:12:17 +0000

I would see the treatment in the network to be slightly different between receiving a pre versus mid call 666 response.

Both would be fed into data analytics.
Pre 666 would be used for the individual profile (possibly adding number to a blacklist), and used in the data analytics for further analysis with other calls to other users.
Post 666 would initiate the reporting and traceback processes.

Regards,

Martin

-----Original Message-----
From: dispatch [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Wednesday, October 12, 2016 4:01 PM
To: Henning Schulzrinne <[email-masked]>; Asveren, Tolga <[email-masked]>
Cc: [email-masked]
Subject: Re: [dispatch] Two new VoIP spam drafts

Henning,

> (2) Increment the bad reputation score for the caller.

Trying to use the same signal to trigger both of these effects presents some issues. And I think they differ for Pre-call and mid-call?

(1) seems appropriate for pre-call. It is clear that I am making a judgement based on the identity of the caller. Not so clear for mid-call. I definitely don't like the content, but that may or may not correlate to the caller identity. Risky to block the caller based on just this.

(2) This action might be appropriate for both pre-call and mid-call, but the two types should probably be tallied separately and evaluated differently. For mid-call I am objecting to the content and the tally is used to see if the number has a history of bad content. For pre-call we really don't know what the callee is objecting to. Still worth tracking, but not as strong a measure.

Of course we aren't standardizing this behavior, so discussing it is just for context.

My bottom line here is just that it is hard to characterize the meaning of the code in a phrase. So I suggest using something quite vague, like "Objectionable" without qualification as to whether it is the calling id, calling name, content, or whatever that it applies to. The text description can go into more detail. But ultimately the meaning will be determined by others so we should be vague enough to cover whatever they decide to do.

	Thanks,
	Paul

---

From: Michael Hammer <[email-masked]>
Date: Thu, 13 Oct 2016 13:45:47 +0000

In addition, it might be necessary to cross-correlate the pre- and mid-call
data.

It could very well turn out that the first call is answered and rejected,
and the second call is rejected pre-call, but the user has figured out that
the presented information (e.g. what happens if both numbers show up with
the same or similar user name and business names and timing?) for the second
call is likely same as the first number?
Could be some non-artificial intelligence going on here.

Bottom line, the customer may recognize porn, I mean spam when he sees it.
And the customer is always right.  :)

Just keep in mind that this is all fuzzy, crowd-sourced information.
No one call may have wider impact than another.

-----Original Message-----
From: dispatch [mailto:[email-masked]] On Behalf Of DOLLY, MARTIN
C
Sent: Thursday, October 13, 2016 8:12 AM
To: Paul Kyzivat <[email-masked]>; Henning Schulzrinne
<[email-masked]>; Asveren, Tolga <[email-masked]>
Cc: [email-masked]
Subject: Re: [dispatch] Two new VoIP spam drafts

I would see the treatment in the network to be slightly different between
receiving a pre versus mid call 666 response.

Both would be fed into data analytics.
Pre 666 would be used for the individual profile (possibly adding number to
a blacklist), and used in the data analytics for further analysis with other
calls to other users.
Post 666 would initiate the reporting and traceback processes.

Regards,

Martin

-----Original Message-----
From: dispatch [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Wednesday, October 12, 2016 4:01 PM
To: Henning Schulzrinne <[email-masked]>; Asveren, Tolga
<[email-masked]>
Cc: [email-masked]

Henning,

On 10/12/16 3:34 PM, Henning Schulzrinne wrote:
> * Pre-call: For example, the Call-Info header in my other draft or CNAM
("Cardholder Serv") lead the called party to hit the "spam" button before
picking up. This yields a 666 response to the INVITE.
>
> * Mid-call: The called party picks up, listens for 10 seconds, decides
they don't need "Microsoft" technical support, and hits the same spam
button.  Signaled via BYE with Reason 666.
> (2) Increment the bad reputation score for the caller.

Trying to use the same signal to trigger both of these effects presents some
issues. And I think they differ for Pre-call and mid-call?

(1) seems appropriate for pre-call. It is clear that I am making a judgement
based on the identity of the caller. Not so clear for mid-call. I definitely
don't like the content, but that may or may not correlate to the caller
identity. Risky to block the caller based on just this.

(2) This action might be appropriate for both pre-call and mid-call, but the
two types should probably be tallied separately and evaluated differently.
For mid-call I am objecting to the content and the tally is used to see if
the number has a history of bad content. For pre-call we really don't know
what the callee is objecting to. Still worth tracking, but not as strong a
measure.

Of course we aren't standardizing this behavior, so discussing it is just
for context.

My bottom line here is just that it is hard to characterize the meaning of
the code in a phrase. So I suggest using something quite vague, like
"Objectionable" without qualification as to whether it is the calling id,
calling name, content, or whatever that it applies to. The text description
can go into more detail. But ultimately the meaning will be determined by
others so we should be vague enough to cover whatever they decide to do.

	Thanks,
	Paul

> I don't see this response affecting a whole category of calls. For
example, I may decide that I really don't like the Police Benevolence
Association call I just received, but that does not necessarily mean that
I'd like to block the American Heart Association. I think category-based
blocking is going to be set up via a more sophisticated web mechanism that
allows finer grained controls ("No charities after 6 pm; only charities with
a Charity Navigator rating of A"). Same for political calls - I may want to
receive the town hall calls from the politician I like and never again hear
from the one I don't.
>
> Spoofing obviously makes call blocking of any sort more problematic, but
much spoofing is from numbers that would never call me. For example,
blocking the "IRS" doesn't prevent the real IRS from calling me - they don't
use the 800# (800-TAX-1040) for outbound calls.
>
> For now, many robocallers don't spoof since they want you to call back,
given that many people let unknown callers go to voicemail.
> Is it because I recognize the number? Or is it based on the classification
assigned by the provider that has been displayed to me?
> These are two different semantics. Perhaps they can share the same code,
since they can be distinguished because they are signaled in different ways.
But it would be cleaner if they were different codes.
answered the call, but not corroborated by others flagging it after
answering, then the situation is unclear. Perhaps this number carries a
calling name that leads people to reject it? Or perhaps it is a number that
is special enough to be recognized by a lot of people. I think this would
need to be investigated carefully to understand what is going on.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Oct 2016 12:22:30 -0400

+1