Subject: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-02.txt

From: [email-masked]
Date: Thu, 12 Jan 2017 13:52:20 -0800

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

        Title           : A SIP Response Code for Unwanted Calls
        Author          : Henning Schulzrinne
	Filename        : draft-ietf-sipcore-status-unwanted-02.txt
	Pages           : 7
	Date            : 2017-01-12

Abstract:
   This document defines the 666 (Unwanted) SIP response code, allowing
   called parties to indicate that the call or message was unwanted.
   SIP entities may use this information to adjust how future calls from
   this calling party are handled for the called party or more broadly.

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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-sipcore-status-unwanted-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-status-unwanted-02

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

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 13 Jan 2017 17:05:05 -0500

While reviewing this version I got to thinking about the use of Reason: 
666 in CANCEL. This could conceivably be abused:

- Alice (bad actor) sends INVITE to Bob
- Bob sends 180 back to Alice
- Alice sends CANCEL with Reason 666

This allows Alice to probe for the presence of a device at the target 
address, while possibly preventing the attempt from being reported to 
the callee.

(This is behavior I see almost every day. While annoying, I'd rather 
have the opportunity to know it happened.)

The only reasonable work-around I see for it is for the proxy servicing 
Bob's AoR to strip the incoming reason code. That would probably be an 
ok thing to do in most cases. But it won't do the right thing if there 
was forking upstream of that proxy. (E.g., in a case where the call was 
originally to a different number and was diverted with forking.)

So this isn't a reason to disallow 666 in CANCEL, but it suggests that 
the processing of this in the UAS be carefully considered.

Otherwise the new version looks good.

	Thanks,
	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 15 Jan 2017 20:53:02 +0000

Good point. Maybe the devices should keep a separate "bad call" list, similar to the spam folder. However, that reporting is probably not going to help Bob a whole lot - assuming Bob doesn't know Alice, what would it do with the information? As you state, it's going to be very hard to distinguish legitimate upstream forking from malicious probing.

________________________________
From: sipcore <[email-masked]> on behalf of Paul Kyzivat <[email-masked]>
Sent: Friday, January 13, 2017 5:05:05 PM
To: SIPCORE
Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt

        Thanks,
        Paul

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

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 18 Jan 2017 10:13:57 +0000

How likely it is that that Bob's UE generates 180 but did not "ring" before such an evil CANCEL is received?

The entity making use of Reason header, e .g. an Application Server managing devices at a call center, can use Contact/Via headers to determine the origin of CANCEL (well, unless there is a B2BUA in-between; but then just as a note: nowadays it is not uncommon that some B2BUAs can relay Via headers between two legs).

Overall, I don't think there is something here which should cause us to lose sleep.

Thanks,
Tolga

From: sipcore [mailto:[email-masked]] On Behalf Of Henning Schulzrinne
Sent: Sunday, January 15, 2017 3:53 PM
To: Paul Kyzivat <[email-masked]>; SIPCORE <[email-masked]>
Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt

________________________________
From: sipcore <[email-masked]<mailto:[email-masked]>> on behalf of Paul Kyzivat <[email-masked]<mailto:[email-masked]>>
Sent: Friday, January 13, 2017 5:05:05 PM
To: SIPCORE
Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt

        Thanks,
        Paul

_______________________________________________
sipcore mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_sipcore&d=DgICAg&c=y0h0omCe0jAUGr4gAQ02Fw&r=FJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=x6C_h7TZev8v8TlNDPl-QNQCHH6Stdtps3jqfVd3AMk&s=yO7o9XY0u_fyn91L6BM8dYU_xw_BtUuq4LBc6IdMT60&e=

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 Jan 2017 11:04:35 -0500

On 1/18/17 5:13 AM, Asveren, Tolga wrote:
> How likely it is that that Bob’s UE generates 180 but did not “ring”
> before such an evil CANCEL is received?

Hard to say. But this sort of behavior is not just theoretical. I get 
calls like this nearly every day. Sometimes I hear (1) ring, sometimes 
none. The charitable interpretation is that someone dialed a wrong 
number and realized immediately. But in my experience this is almost 
never the cause. I often follow up these, by checking the call log and 
googling the number. Usually I find many reports of bad behavior from 
that number.

> The entity making use of Reason header, e .g. an Application Server
> managing devices at a call center, can use Contact/Via headers to
> determine the origin of CANCEL (well, unless there is a B2BUA
> in-between; but then just as a note: nowadays it is not uncommon that
> some B2BUAs can relay Via headers between two legs).

I presume that typically the entity making use of the reason header will 
be the called UAS and/or the home proxy for the callee's AoR (probably 
the callee's SP.) The use case mentioned in this thread is by the UAS, 
when managing its own log of incoming calls.

It is unclear to me whether common deployments would preserve the Via 
headers that would allow deciphering whether the cancel was due to 
forking or an overt action by the UAC.

> Overall, I don’t think there is something here which should cause us to
> lose sleep.

I'm not losing sleep over it. But the bad actors are not going to go 
away quietly once these new mechanisms are put in place. They will 
certainly seek out holes that can be exploited. So there is value in 
trying to close as many potential holes as we can.

In any case I didn't see any obvious fix for this. But the consequence 
is the need to be careful not to ascribe too much meaning to the receipt 
of the 666 in cancel.

	Thanks,
	Paul

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 19 Jan 2017 11:58:35 +0000

I am having a hard time to understand the attack vector on this scenario. What is the attacker trying to achieve? 
That a randomly chosen "number" is an actual DN? That information is already available in Yellow Pages or can be obtained relatively easily through "random walk". Invalid numbers will be rejected as "This number is not in service".
Or is the attacker trying to figure out the core-network entity SIP address (at least one of the many) associated with a DN? What would be the purpose of doing so?

If there really is an issue here, it can be mitigated by the operator providing a portal/service number to report such numbers. This is not what 666 is intended for IMHO. Overall, I am happy that no text changes are foreseen due to this scenario.

Thanks,
Tolga

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Wednesday, January 18, 2017 11:05 AM
> To: Asveren, Tolga <[email-masked]>; Henning Schulzrinne
> <[email-masked]>; SIPCORE <[email-masked]>
> Hard to say. But this sort of behavior is not just theoretical. I get calls like this
> nearly every day. Sometimes I hear (1) ring, sometimes none. The charitable
> interpretation is that someone dialed a wrong number and realized
> immediately. But in my experience this is almost never the cause. I often
> follow up these, by checking the call log and googling the number. Usually I
> find many reports of bad behavior from that number.
> 
> I presume that typically the entity making use of the reason header will be
> the called UAS and/or the home proxy for the callee's AoR (probably the
> callee's SP.) The use case mentioned in this thread is by the UAS, when
> managing its own log of incoming calls.
> 
> headers that would allow deciphering whether the cancel was due to forking
> or an overt action by the UAC.
> 
> I'm not losing sleep over it. But the bad actors are not going to go away
> quietly once these new mechanisms are put in place. They will certainly seek
> out holes that can be exploited. So there is value in trying to close as many
> potential holes as we can.
> 
> In any case I didn't see any obvious fix for this. But the consequence is the
> need to be careful not to ascribe too much meaning to the receipt of the 666
> in cancel.
> 
> 	Thanks,
> 	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 19 Jan 2017 10:58:57 -0500

> If there really is an issue here, it can be mitigated by the operator providing a portal/service number to report such numbers. This is not what 666 is intended for IMHO. Overall, I am happy that n…

I don't know what the goal of the attack is. But there must be one, 
because it occurs with regularity. I get these multiple times per week, 
as do others I have asked about it. And querying the calling number 
typically turns up others who have received similar calls.

	Thanks,
	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 19 Jan 2017 16:02:33 +0000

I have heard that these are simply scanning attacks - trying to find open SIP proxies that can be used as intermediaries for hiding (DOS) attacks or spam, or to probe for poorly-secured systems to use for toll fraud.

Google for "SIP scanner" and you'll find articles such as
http://serverfault.com/questions/549134/how-can-i-stop-sipvicious-friendly-scanner-from-flooding-my-sip-server

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Thursday, January 19, 2017 10:59 AM
To: Asveren, Tolga <[email-masked]>; Henning Schulzrinne <[email-masked]>; SIPCORE <[email-masked]>
Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt

> If there really is an issue here, it can be mitigated by the operator providing a portal/service number to report such numbers. This is not what 666 is intended for IMHO. Overall, I am happy that n…

I don't know what the goal of the attack is. But there must be one, because it occurs with regularity. I get these multiple times per week, as do others I have asked about it. And querying the calling number typically turns up others who have received similar calls.

	Thanks,
	Paul

>> calls like this nearly every day. Sometimes I hear (1) ring, 
>> sometimes none. The charitable interpretation is that someone dialed 
>> a wrong number and realized immediately. But in my experience this is 
>> almost never the cause. I often follow up these, by checking the call 
>> log and googling the number. Usually I find many reports of bad behavior from that number.
>>
>>> in-between; but then just as a note: nowadays it is not uncommon 
>>> that some B2BUAs can relay Via headers between two legs).
>>
>> I presume that typically the entity making use of the reason header 
>> will be the called UAS and/or the home proxy for the callee's AoR 
>> (probably the callee's SP.) The use case mentioned in this thread is 
>> by the UAS, when managing its own log of incoming calls.
>>
>> In any case I didn't see any obvious fix for this. But the 
>> consequence is the need to be careful not to ascribe too much meaning 
>> to the receipt of the 666 in cancel.
>>
>> 	Thanks,
>> 	Paul
>
>

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 19 Jan 2017 16:29:27 +0000

Yes, that certainly there and is not something new but what is the rationale behind "not ringing" and even trying a "legitimate DN"? Or in other words, is there any additional concern arising from use of 666; AFAICS no.

Thanks,
Tolga

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Thursday, January 19, 2017 11:03 AM
> To: Paul Kyzivat <[email-masked]>; Asveren, Tolga
> <[email-masked]>; SIPCORE <[email-masked]>
> Subject: RE: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt
> 
> I have heard that these are simply scanning attacks - trying to find open SIP
> proxies that can be used as intermediaries for hiding (DOS) attacks or spam,
> or to probe for poorly-secured systems to use for toll fraud.
> 
> http://serverfault.com/questions/549134/how-can-i-stop-sipvicious-
> friendly-scanner-from-flooding-my-sip-server
> 
> > That a randomly chosen "number" is an actual DN? That information is
> already available in Yellow Pages or can be obtained relatively easily through
> "random walk". Invalid numbers will be rejected as "This number is not in
> service".
> > Or is the attacker trying to figure out the core-network entity SIP address
> (at least one of the many) associated with a DN? What would be the purpose
> of doing so?
> >
> > If there really is an issue here, it can be mitigated by the operator providing
> a portal/service number to report such numbers. This is not what 666 is
> intended for IMHO. Overall, I am happy that no text changes are foreseen
> due to this scenario.
> 
> I don't know what the goal of the attack is. But there must be one, because it
> occurs with regularity. I get these multiple times per week, as do others I
> have asked about it. And querying the calling number typically turns up
> others who have received similar calls.
> 
> 	Thanks,
> 	Paul
> 
> > Thanks,
> > Tolga
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 19 Jan 2017 11:50:35 -0500

> Yes, that certainly there and is not something new but what is the rationale behind "not ringing" and even trying a "legitimate DN"? Or in other words, is there any additional concern arising from…

I guess it depends on what might happen on the 2nd and subsequent calls 
from that number. If there are no subsequent calls then it doesn't 
matter much.

But the suggestion was for the recipient to use the receipt of 666 in 
cancel to suppress adding the number to the missed call list. If *these* 
calls are omitted from the missed call list then I won't know they 
occurred. Hence I won't be wary if I get subsequent calls.

I don't know if this could be a threat or not. The point is that it is a 
use case that (with only local knowledge) is indistinguishable from the 
one that people have in mind.

	Thanks,
	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 19 Jan 2017 17:04:03 +0000

I think there's a difference between the average, non-technical user who will not be able to do anything useful with the bogus call information and will appreciate not having their calling list cluttered with robocalls, and the technical user, such as yourself and system administrators, who do need this information. My sense is that logging and automated log analysis are better suited to analyzing potential threats than small screens on desktop devices deployed on the desktop of administrative assistants.

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Thursday, January 19, 2017 11:51 AM
To: Asveren, Tolga <[email-masked]>; Henning Schulzrinne <[email-masked]>; SIPCORE <[email-masked]>
Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt

> Yes, that certainly there and is not something new but what is the rationale behind "not ringing" and even trying a "legitimate DN"? Or in other words, is there any additional concern arising from…

I guess it depends on what might happen on the 2nd and subsequent calls from that number. If there are no subsequent calls then it doesn't matter much.

But the suggestion was for the recipient to use the receipt of 666 in cancel to suppress adding the number to the missed call list. If *these* calls are omitted from the missed call list then I won't know they occurred. Hence I won't be wary if I get subsequent calls.

I don't know if this could be a threat or not. The point is that it is a use case that (with only local knowledge) is indistinguishable from the one that people have in mind.

	Thanks,
	Paul

>> I have heard that these are simply scanning attacks - trying to find 
>> open SIP proxies that can be used as intermediaries for hiding (DOS) 
>> attacks or spam, or to probe for poorly-secured systems to use for toll fraud.
>>
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__serverfault.com_q
>> uestions_549134_how-2Dcan-2Di-2Dstop-2Dsipvicious-2D&d=DwIC-g&c=y0h0o
>> mCe0jAUGr4gAQ02Fw&r=FJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=9AG
>> yoCJcrekSufonBTh9woDx8W9b3JlAz43e4Avy30c&s=GB-f66SfRxHY4yTRvGhaCTU7fs
>> PaSh6CmxtuDRiWp-Q&e= friendly-scanner-from-flooding-my-sip-server
>>
>> already available in Yellow Pages or can be obtained relatively 
>> easily through "random walk". Invalid numbers will be rejected as 
>> "This number is not in service".
>> (at least one of the many) associated with a DN? What would be the 
>> purpose of doing so?
>>>
>> a portal/service number to report such numbers. This is not what 666 
>> is intended for IMHO. Overall, I am happy that no text changes are 
>> foreseen due to this scenario.
>>
>> because it occurs with regularity. I get these multiple times per 
>> week, as do others I have asked about it. And querying the calling 
>> number typically turns up others who have received similar calls.
>>
>> 	Thanks,
>> 	Paul
>>
>>> Thanks,
>>> Tolga
>>>
>>>> Hard to say. But this sort of behavior is not just theoretical. I 
>>>> get calls like this nearly every day. Sometimes I hear (1) ring, 
>>>> sometimes none. The charitable interpretation is that someone 
>>>> dialed a wrong number and realized immediately. But in my 
>>>> experience this is almost never the cause. I often follow up these, 
>>>> by checking the call log and googling the number. Usually I find 
>>>> many reports of bad behavior
>> from that number.
>>>>
>>>>> The entity making use of Reason header, e .g. an Application 
>>>>> Server managing devices at a call center, can use Contact/Via 
>>>>> headers to determine the origin of CANCEL (well, unless there is a 
>>>>> B2BUA in-between; but then just as a note: nowadays it is not 
>>>>> uncommon that some B2BUAs can relay Via headers between two legs).
>>>>
>>>> (probably the callee's SP.) The use case mentioned in this thread 
>>>> is by the UAS, when managing its own log of incoming calls.
>>>>
>>>> It is unclear to me whether common deployments would preserve the 
>>>> Via headers that would allow deciphering whether the cancel was due 
>>>> to forking or an overt action by the UAC.
>>>>
>>>> I'm not losing sleep over it. But the bad actors are not going to 
>>>> go away quietly once these new mechanisms are put in place. They 
>>>> will certainly seek out holes that can be exploited. So there is 
>>>> value in trying to close as many potential holes as we can.
>>>>
>>>> consequence is the need to be careful not to ascribe too much 
>>>> meaning to the receipt of the 666 in cancel.
>>>>
>>>> 	Thanks,
>>>> 	Paul
>>>
>>>
>
>

---

From: Richard Shockey <[email-masked]>
Date: Thu, 19 Jan 2017 13:40:58 -0500

Big +1 to Henning’s observations here.  In nearly all the discussions of the SHAKEN framework there has been this concept of a data analytics engine at the terminating service provider network that could compile data not just from STIR validation but from a variety of sources such as 666 notifications.  Based on the clear consumer preference, the engine could take several actions one of which might be to block the call or score the call and ultimately present that data to the CUA under conditions that the consumer signs up to. 

I’m well aware of several companies developing these call analytics engines. 

— 
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 1/19/17, 12:04 PM, "sipcore on behalf of Henning Schulzrinne" <[email-masked] on behalf of [email-masked]> wrote:

    -----Original Message-----
    From: Paul Kyzivat [mailto:[email-masked]] 
    Sent: Thursday, January 19, 2017 11:51 AM
    To: Asveren, Tolga <[email-masked]>; Henning Schulzrinne <[email-masked]>; SIPCORE <[email-masked]>
    Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt

    

    	Thanks,
    	Paul

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

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 20 Jan 2017 15:42:21 +0000

I reviewed this version and it looks ready for WGLC.

I only have the following suggestion:

   The called user
   agent (UAS), based on input from the called party or some UA-internal
   logic, uses this to indicate that future calls from the same caller
   are also unwanted.
=>
   The called user
   agent (UAS), based on input from the called party or some UA-internal
   logic, uses this to indicate that this call is unwanted.

I know I keep harping on this -and will stop doing so after this time- but this change IMHO would highlight a philosophically important point and not being clear on this aspect has been the root cause of many discussions so far AFAICS -and likely to cause confusing on future readers of the specification, who were not part of thereof-.

Thanks,
Tolga

> From: sipcore [mailto:[email-masked]] On Behalf Of internet-
> [email-masked]
> Sent: Thursday, January 12, 2017 4:52 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-02.txt
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 20 Jan 2017 13:29:19 -0500

> I know I keep harping on this -and will stop doing so after this time- but this change IMHO would highlight a philosophically important point and not being clear on this aspect has been the root ca…

I support this.

In principle this is a choice we can make. But it is important for the 
end user who is pushing the button to understand which meaning it is. 
Getting end users to internalize this distinction will be difficult. I'm 
inclined to think that it will be easier for people to grasp the meaning 
"I don't want this call".

Of course we intend to use this feedback to identify callers whose calls 
are unwanted. But I think that is an inference rather than a consequence.

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Sun, 22 Jan 2017 21:22:06 -0500

"Asveren, Tolga" <[email-masked]> writes:
> I know I keep harping on this -and will stop doing so after this time-
> but this change IMHO would highlight a philosophically important point
> and not being clear on this aspect has been the root cause of many
> discussions so far AFAICS -and likely to cause confusing on future
> readers of the specification, who were not part of thereof-.

It seems to me that this is very important.  We want to make sure the
*meaning* of the 666 response is well-defined.  Otherwise, we will have
an interoperability nightmare.  And the meaning that we can define and
that the user can understand is "I don't like this call."

But it's messy to go from that to any particular inference as to which
future calls should be automatically rejected.  The current text says
"from the same caller", but we've discovered that it's impossible to
provide a clear definition of that (at least at this time).

I think it's a lot better to leave the decision-making process open to
future research.

Dale

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 23 Jan 2017 22:13:22 +0000

This will be updated in the next version. (I believe the WGLC  concluded a while ago:

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

That said, unless the user believes that this will improve behavior for future calls, they might as well just vent on Twitter or FB.

Henning

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Asveren, Tolga
Sent: Friday, January 20, 2017 10:42 AM
To: SIPCORE <[email-masked]>
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-02.txt

   The called user

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 23 Jan 2017 22:18:59 +0000

While there were *some* cases where there might be ambiguity who is really calling, hopefully STIR will yield a fair and increasing fraction of calls where this is pretty clear, particularly for the typical robocall (i.e., without forwarding and other special treatments).

I suspect we all agree that the details as to the statistical handling of 666 reports for blocking or other specialized call treatment is well beyond the scope of this draft (or the IETF,  most likely).

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Dale R. Worley
Sent: Sunday, January 22, 2017 9:22 PM
To: Asveren, Tolga <[email-masked]>
Cc: [email-masked]
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-02.txt

It seems to me that this is very important.  We want to make sure the
*meaning* of the 666 response is well-defined.  Otherwise, we will have an interoperability nightmare.  And the meaning that we can define and that the user can understand is "I don't like this call."

But it's messy to go from that to any particular inference as to which future calls should be automatically rejected.  The current text says "from the same caller", but we've discovered that it's impossible to provide a clear definition of that (at least at this time).

I think it's a lot better to leave the decision-making process open to future research.

Dale

---

From: Adam Roach <[email-masked]>
Date: Mon, 30 Jan 2017 15:21:19 -0600

[as individual]

> number typically turns up others who have received similar calls. 

FWIW -- and this is a complete diversion -- but it's my understanding is 
that standard operating procedure for many dial-out solicitors is to 
have the system originate several outgoing calls simultaneously, 
frequently exceeding the number of phone agents available. This is based 
on the theory that only a small fraction of them will get answered. When 
the number of answered calls reaches the number of available agents, any 
pending outbound calls are canceled, since the system would have no 
agent to match them with.

Times may have changed, but my understanding is that this practice was 
the reason for a vast majority of "one ring" calls from numbers 
associated with solicitors a decade or so ago.

> address, while possibly preventing the attempt from being reported to 
If we're talking about SIP systems, the 666-based approach you describe 
seems quite overwrought when a simple OPTIONS request would accomplish 
the same goal.

/a

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 30 Jan 2017 22:44:26 +0000

There are rules about "dead air", so this makes sense. See also

https://epic.org/privacy/telemarketing/

One-ring calls are also used for inducing the called party to call back, racking up charges to some Caribbean Island in the +1 country code.

-----Original Message-----
From: Adam Roach [mailto:[email-masked]] 
Sent: Monday, January 30, 2017 4:21 PM
To: Paul Kyzivat <[email-masked]>; Asveren, Tolga <[email-masked]>; Henning Schulzrinne <[email-masked]>; SIPCORE <[email-masked]>
Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt

[as individual]

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 31 Jan 2017 10:20:45 -0500

> https://epic.org/privacy/telemarketing/

I have heard of such but never encountered them.

> One-ring calls are also used for inducing the called party to call back, racking up charges to some Caribbean Island in the +1 country code.

Most of the ones I encounter are of this variety. Some I have confirmed 
first hand, others second hand. But there are a *lot* of them. I get 
multiples per day, to my mobile, and to a vonage number that is IIUC 
assigned from the mobile number pool.

I don't know if they are of the sort that Adam described or are 
intentionally one-ring calls.

But this discussion isn't going anywhere, so I'm happy to end it.

	Thanks,
	Paul