[VoiceOps] Fake Voicemail Anti-Robocall Tactics

Calvin Ellison calvin.ellison at voxox.com
Tue Feb 16 12:31:08 EST 2021


The issue I have with this tactic is the impact it has on intermediate
carriers who specifically service aggregate call center traffic, where the
nefarious traffic is blended upstream and more difficult to detect. The
upstream clients expect us to prevent it, and when we can't, it becomes a
trust issue and then ultimately a revenue issue, on top of the support
resources spend handling the complaints. We don't want to facilitate the
nefarious traffic either and are implementing our own call blocking, but
we're not going to scam every hop in between in the process.

This practice also directly conflicts with the recent FCC requirement to
use SIP 607 or 608 responses when blocking calls:

iii)              Enhanced Transparency and Redress Requirements – The
FCC requires
> terminating voice service providers that block calls to immediately notify
> the caller that the call has been blocked by sending either a Session
> Initiation Protocol (IP network return SIP Code 607 or 608) or ISDN User
> Part (ISUP Code 21) response code, as appropriate, and requires all voice
> service providers in the call path to transmit these codes to the
> origination point.  Second, the FCC requires terminating voice service
> providers that block calls on an opt-in or opt-out basis to disclose to
> their subscribers a list of blocked calls (on an opt-in or opt-out basis)
> within three business days of a request. Third, when a calling party
> disputes whether blocking its calls is appropriate, the FCC requires
> terminating voice service providers to provide a status update to the party
> that filed the dispute within 24 hours and that the point of contact which
> terminating voice service providers have established to handle blocking
> disputes also handle contacts from callers that are adversely affected by
> information provided by caller ID authentication seeking to verify the
> authenticity of their calls. Finally, the FCC declined to address the
> issue of erroneous labeling at this time.  The FCC gave voice service
> providers until January 1, 2022 to comply with the immediate notification
> requirements.
>

https://docs.fcc.gov/public/attachments/FCC-20-187A1.pdf

Regards,

*Calvin Ellison*
Systems Architect
calvin.ellison at voxox.com
+1 (213) 285-0555

-----------------------------------------------
*voxox.com <http://www.voxox.com/> *
5825 Oberlin Drive, Suite 5
San Diego, CA 92121
[image: Voxox]


On Tue, Feb 16, 2021 at 9:07 AM Brandon Svec <bsvec at teamonesolutions.com>
wrote:

> True, but it doesn't matter.  Since there are bad actors that we are
> trying to prevent, then all spoofed numbers must be handled correctly.  It
> can no longer be ok to just look the other way and let them all through.
> Validated/authorized spoofed numbers should be fine and those that are not
> have work to do and all that should be left are bad actors being blocked.
> Of course, I understand we are not quite there yet, but this is how it
> *should* be.
>
> *Brandon Svec*
>
> *15106862204 <15106862204> voice|sms**teamonesolutions.com
> <https://teamonesolutions.com/>*
>
>
> On Tue, Feb 16, 2021 at 9:00 AM Brooks Bridges <
> brooks at firestormnetworks.net> wrote:
>
>> I would posit that outpulsing a specific ANI with authorization of, and
>> at the request of, the number's owner doesn't really fall under the
>> colloquial understanding of "spoofing".  I think that term is typically
>> used to imply malice or deceit.
>>
>> On 2/16/2021 8:44 AM, Carlos Alvarez wrote:
>>
>> But the ridiculous side of this is that there are valid reasons to
>> "spoof" numbers.  We have two customers who need to do it all the time, and
>> it's legal, as well as demanded by their customers.
>>
>>
>> On Tue, Feb 16, 2021 at 9:37 AM <paul at timmins.net> wrote:
>>
>>> Legal or not it’s genius. Humans will notice right away and it’ll cost
>>> for the robocallers.
>>>
>>> Sent from my iPhone
>>>
>>> On Feb 16, 2021, at 11:23 AM, Calvin Ellison <calvin.ellison at voxox.com>
>>> wrote:
>>>
>>> 
>>> Today we received a notice from one of our underlying carriers that
>>> included the following statement:
>>>
>>> * If a customer spoofs an ANI that they do not own, the clec's can
>>>> forward to call to a voiceless Voicemail which appears to be FAS.
>>>>
>>>
>>> Is there any legal device that actually supports this practice? I'm
>>> looking for a specific statute, FCC rule, precedent in a judicial ruling,
>>> or the like.
>>>
>>> The FCC has ruled that the SIP 608 response code is to be used for
>>> signaling when a call is rejected. I doubt the FCC or FTC has ruled that
>>> terminating carriers are permitted to cause loss of trust and revenue
>>> between upstream intermediate and originating carriers.
>>>
>>>
>>> Regards,
>>>
>>> *Calvin Ellison*
>>> Systems Architect
>>> calvin.ellison at voxox.com
>>> +1 (213) 285-0555
>>>
>>> -----------------------------------------------
>>> *voxox.com <http://www.voxox.com/> *
>>> 5825 Oberlin Drive, Suite 5
>>> San Diego, CA 92121
>>> [image: Voxox]
>>> _______________________________________________
>>> VoiceOps mailing list
>>> VoiceOps at voiceops.org
>>> https://puck.nether.net/mailman/listinfo/voiceops
>>>
>>> _______________________________________________
>>> VoiceOps mailing list
>>> VoiceOps at voiceops.org
>>> https://puck.nether.net/mailman/listinfo/voiceops
>>>
>>
>> _______________________________________________
>> VoiceOps mailing listVoiceOps at voiceops.orghttps://puck.nether.net/mailman/listinfo/voiceops
>>
>>
>> _______________________________________________
>> VoiceOps mailing list
>> VoiceOps at voiceops.org
>> https://puck.nether.net/mailman/listinfo/voiceops
>>
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20210216/7d37bf5a/attachment-0001.htm>


More information about the VoiceOps mailing list