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

From: Anton Tveretin <[email-masked]>
Date: Mon, 14 Nov 2016 11:21:23 +0500

I assume:
603 = This call is unwanted for me
603 with Expires: = This caller is unwanted for me
666 with or without Expires: = This caller is unwanted for me, and probably for other users
I am unsure:
403 = This call is unwanted, but the operator may forward it.

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Mon, 14 Nov 2016 06:53:57 +0000

The user interface needs to be simple, therefore a single button resulting in the 666 being sent to the network.

The 666 is passed to the data analytics data base, where the appropriate actions are taken depending on:
1) was the 666 pre- or post-answer;
2) subscriber's profile;
3) reputation associated of the Calling Number

Actions to be taken can vary from one to all of the following:
1) block that Calling Number on future calls
2) update reputation of that Calling Number
3) initiate traceback procedures
4) issue scam/fraud report to FCC/FTC

Note, the action(s) taken would likely vary over time taking into account changes in the subscribers profile and changes in the attack vector

Regards,

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

-----Original Message-----
From: dispatch [mailto:[email-masked]] On Behalf Of Anton Tveretin
Sent: Monday, November 14, 2016 1:21 AM
To: DISPATCH list <[email-masked]>
Subject: Re: [dispatch] Two new VoIP spam drafts

I assume:
603 = This call is unwanted for me
603 with Expires: = This caller is unwanted for me
666 with or without Expires: = This caller is unwanted for me, and probably for other users I am unsure:
403 = This call is unwanted, but the operator may forward it.

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 14 Nov 2016 08:24:00 +0000

I agree - there is no evidence that users will want to deal with more complexity, or remember the differences between different actions. I'm not aware of any email client that has more than a basic "junk" or "spam" button. The only mail-specific variation is that gmail pops up a modal window for messages that have List-* headers, to allow unsubscribing instead of or in addition to marking it as spam. You could imagine some version of that for phone calls, to be used by legitimate entities that want to make it easy for people to get off their phone list, but that seems like a longer-term problem.

________________________________
From: dispatch <[email-masked]> on behalf of DOLLY, MARTIN C <[email-masked]>
Sent: Monday, November 14, 2016 1:53:57 AM
To: Anton Tveretin; DISPATCH list
Subject: Re: [dispatch] Two new VoIP spam drafts

Regards,

Martin C. Dolly

-----Original Message-----
From: dispatch [mailto:[email-masked]] On Behalf Of Anton Tveretin
Sent: Monday, November 14, 2016 1:21 AM
To: DISPATCH list <[email-masked]>
Subject: Re: [dispatch] Two new VoIP spam drafts

I assume:

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 14 Nov 2016 11:12:44 -0500

On 11/14/16 3:24 AM, Henning Schulzrinne wrote:
> I agree - there is no evidence that users will want to deal with more
> complexity, or remember the differences between different actions. I'm
> not aware of any email client that has more than a basic "junk" or
> "spam" button. The only mail-specific variation is that gmail pops up a
> modal window for messages that have List-* headers, to allow
> unsubscribing instead of or in addition to marking it as spam. You could
> imagine some version of that for phone calls, to be used by legitimate
> entities that want to make it easy for people to get off their phone
> list, but that seems like a longer-term problem.

I agree with this argument for simplicity - one button.

But I think it is important to make it clear to end users what that 
button means, so it is used appropriately, and that the provider actions 
are consistent with what the users are told.

As Martin spelled it out there are a number of possible actions that 
could result. If all providers do more or less the same thing, and that 
is consistent with what callers are led to believe, that all will be 
good. OTOH, if providers use significantly different logic, then their 
customers may have a different understanding of what the button means. 
That can lead to a mess.

Then the question becomes whether the definition of the response code 
should be the same as the definition of the presumed button.

	Thanks,
	Paul

> ------------------------------------------------------------------------
> *From:* dispatch <[email-masked]> on behalf of DOLLY, MARTIN
> C <[email-masked]>
> *Sent:* Monday, November 14, 2016 1:53:57 AM
> *To:* Anton Tveretin; DISPATCH list
> *Subject:* Re: [dispatch] Two new VoIP spam drafts
>
> The user interface needs to be simple, therefore a single button
> resulting in the 666 being sent to the network.
>
> Note, the action(s) taken would likely vary over time taking into
> account changes in the subscribers profile and changes in the attack vector
>
> Regards,
>
> Martin C. Dolly

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Mon, 14 Nov 2016 19:42:18 +0000

Paul

We are defining Best Practices in the IPNNI

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 Nov 15, 2016, at 1:12 AM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:

But I think it is important to make it clear to end users what that button means, so it is used appropriately, and that the provider actions are consistent with what the users are told.

As Martin spelled it out there are a number of possible actions that could result. If all providers do more or less the same thing, and that is consistent with what callers are led to believe, that all will be good. OTOH, if providers use significantly different logic, then their customers may have a different understanding of what the button means. That can lead to a mess.

Then the question becomes whether the definition of the response code should be the same as the definition of the presumed button.

   Thanks,
   Paul

------------------------------------------------------------------------
*From:* dispatch <[email-masked]<mailto:[email-masked]>> on behalf of DOLLY, MARTIN
C <[email-masked]<mailto:[email-masked]>>
*Sent:* Monday, November 14, 2016 1:53:57 AM
*To:* Anton Tveretin; DISPATCH list
*Subject:* Re: [dispatch] Two new VoIP spam drafts

The 666 is passed to the data analytics data base, where the appropriate
actions are taken depending on:
1) was the 666 pre- or post-answer;
2) subscriber's profile;
3) reputation associated of the Calling Number

Regards,

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

-----Original Message-----
From: dispatch [mailto:[email-masked]] On Behalf Of Anton
Tveretin
Sent: Monday, November 14, 2016 1:21 AM
To: DISPATCH list <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dispatch] Two new VoIP spam drafts

I assume:
603 = This call is unwanted for me
603 with Expires: = This caller is unwanted for me
666 with or without Expires: = This caller is unwanted for me, and
probably for other users I am unsure:
403 = This call is unwanted, but the operator may forward it.

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

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

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

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 14 Nov 2016 16:36:16 -0500

Martin,

> We are defining Best Practices in the IPNNI

Does this mean that all the providers will be acting reasonably 
consistently, to the extent that a user can use the same criteria for 
deciding whether or not to mark a call as spam regardless of what 
carrier he is using?

E.g., presumably it will be proper to mark a call as spam if it claims 
to be from a Nigerian prince asking for my help in getting money out of 
his country. But is it also proper for a call from a spouse asking for 
overdue alimony?

Of course users can't be prevented from marking any particular call. But 
over time they will hopefully which cases "do the right thing" and which 
do not, for the carrier they are using. One would hope those learnings 
will carry over between carriers.

	Thanks,
	Paul

> *Martin C. Dolly*
> Cell: +1.609.903.3360 <tel:+1.609.903.3360>
>
> Email: [email-masked] <mailto:[email-masked]>_
>
>
>
>
> On Nov 15, 2016, at 1:12 AM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>> button means, so it is used appropriately, and that the provider
>> actions are consistent with what the users are told.
>>
>> could result. If all providers do more or less the same thing, and
>> that is consistent with what callers are led to believe, that all will
>> be good. OTOH, if providers use significantly different logic, then
>> their customers may have a different understanding of what the button
>> means. That can lead to a mess.
>>
>>> *From:* dispatch <[email-masked]
>>> <mailto:[email-masked]>> on behalf of DOLLY, MARTIN
>>> C <[email-masked] <mailto:[email-masked]>>
>>> Email: [email-masked] <mailto:[email-masked]>
>>>
>>>
>>>
>>> To: DISPATCH list <[email-masked] <mailto:[email-masked]>>
>>> [email-masked] <mailto:[email-masked]>
>>> [email-masked] <mailto:[email-masked]>
>>> [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 14 Nov 2016 16:58:17 -0500

Martin,

I forgot one important thing:

I realize that all of this "usage" stuff is out of scope for us. The 
part that *is* in scope is the response code, or codes, used to signal 
the pressing of "the button". When somebody new is implementing SIP they 
will find that code and wonder how it is to be used. If definition is 
done by IPNNI, then how will they know to look for it? This could be an 
issue for somebody implementing a PBX.

So the key is finding the right words to say in the definition of the 
response code. Perhaps it can *reference* the IPNNI best practices, or 
say something that tells the reader to go looking.

	Thanks,
	Paul

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Mon, 14 Nov 2016 22:08:40 +0000

Paul,

That is correct. The goal is for the user to have a common experience independent of device type or carrier, to the extent possible.

There is a need for consumer education, and yes there will be an ongoing learning period for the carriers.

Regards,

Martin

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Monday, November 14, 2016 4:36 PM
To: DOLLY, MARTIN C <[email-masked]>
Cc: [email-masked]
Subject: Re: [dispatch] Two new VoIP spam drafts

Martin,

> We are defining Best Practices in the IPNNI

Does this mean that all the providers will be acting reasonably consistently, to the extent that a user can use the same criteria for deciding whether or not to mark a call as spam regardless of what carrier he is using?

E.g., presumably it will be proper to mark a call as spam if it claims to be from a Nigerian prince asking for my help in getting money out of his country. But is it also proper for a call from a spouse asking for overdue alimony?

Of course users can't be prevented from marking any particular call. But over time they will hopefully which cases "do the right thing" and which do not, for the carrier they are using. One would hope those learnings will carry over between carriers.

	Thanks,
	Paul

>>> I agree - there is no evidence that users will want to deal with 
>>> more complexity, or remember the differences between different 
>>> actions. I'm not aware of any email client that has more than a 
>>> basic "junk" or "spam" button. The only mail-specific variation is 
>>> that gmail pops up a modal window for messages that have List-* 
>>> headers, to allow unsubscribing instead of or in addition to marking 
>>> it as spam. You could imagine some version of that for phone calls, 
>>> to be used by legitimate entities that want to make it easy for 
>>> people to get off their phone list, but that seems like a longer-term problem.
>>
>> that is consistent with what callers are led to believe, that all 
>> will be good. OTOH, if providers use significantly different logic, 
>> then their customers may have a different understanding of what the 
>> button means. That can lead to a mess.
>>
>>> <mailto:[email-masked]>> on behalf of DOLLY, MARTIN C 
>>> <[email-masked] <mailto:[email-masked]>>
>>> The 666 is passed to the data analytics data base, where the 
>>> appropriate actions are taken depending on:
>>> Core & Government/Regulatory Standards AT&T
>>> Cell: +1.609.903.3360

---

From: Richard Shockey <[email-masked]>
Date: Mon, 14 Nov 2016 17:16:22 -0500

Martin is correct here the concept of a BCP here would be some industry wide agreement on behaivors, especially as it might relate to successful Validation Display perhaps industry agreement on a single graphic logo. 

We are going to try and apply consistant data analyitics as well at termination. That also may involve some data sharing as well but that will have to be worked out with the regulators.

Its early but these are good points for all of us to consider.  

What we are all agreed on is that this needs to be pretty darn simple.  

On 11/14/16, 4:36 PM, "dispatch on behalf of Paul Kyzivat" <[email-masked] on behalf of [email-masked]> wrote:

    Martin,

    

    	Thanks,
    	Paul

---

From: Richard Shockey <[email-masked]>
Date: Mon, 14 Nov 2016 17:25:06 -0500

+1  and one other thing this is not a US specific initiative.  

The CRTC in Ottawa acted last week to spin up activity among the Canadian Carriers.

The actual CRTC order.

http://www.crtc.gc.ca/eng/archive/2016/2016-442.htm

The Canadian Interconnection Steering Group has been empowered to be their strikeforce.

http://www.crtc.gc.ca/eng/cisc-cdci.htm

I just got back from London and the NICC General Meeting ( its sort of their ATIS ) and this was topic #1.

http://www.niccstandards.org.uk/meetings/forum-2016.cfm

It would be a fair bet there will be HMG action as well in 2017.

— 
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

On 11/14/16, 5:08 PM, "dispatch on behalf of DOLLY, MARTIN C" <[email-masked] on behalf of [email-masked]> wrote:

    Paul,

    
    Regards,
    
    Martin
    
    -----Original Message-----
    From: Paul Kyzivat [mailto:[email-masked]] 
    Sent: Monday, November 14, 2016 4:36 PM
    To: DOLLY, MARTIN C <[email-masked]>
    Cc: [email-masked]
    Subject: Re: [dispatch] Two new VoIP spam drafts
    
    Martin,

    

    	Thanks,
    	Paul