Their lawyers probably explained to them that they can "block" the call "after" accepting it and thus can get the best of both world -- the revenue from terminating the call while still preventing it from bothering their customers ...
-- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-----Original Message----- >From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Christopher >Morrow >Sent: Wednesday, 10 July, 2019 22:10 >To: Sean Donelan >Cc: nanog list >Subject: Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC > >On Wed, Jul 10, 2019 at 11:56 PM Sean Donelan <s...@donelan.com> >wrote: >> >> On Tue, 9 Jul 2019, Sean Donelan wrote: >> > The agenda looks like lots of happy, happy talk from industry >> > representatives. >> >> In advance of the SHAKEN/STIR robocall summit, AT&T has issued a >press >> release announcing plans to automatically block robocalls for its >> customers. >> >> https://about.att.com/story/2019/att_call_protect.html >> >> Automatic Blocking of Fraud Calls Coming to Millions of AT&T >Customers >> AT&T* will add automatic fraud blocking and suspected spam-call >alerts to >> millions of AT&T consumer lines at no charge. > >oh goodie! > >So, not being a bell shaped headed person... a question: > The calling path and data available inside the phone network smells >(to me) like: > ingress trunk + ANI + CallerID + outgoing trunk of destination >ds0/handset > >There seem like a bunch of pretty simple 'correlations' one could >make, that actually look a heck of a lot like 'netflow/log analysis >for ddos detection': > o is this trunk sourcing calls to 'too many' of my subs in >period-of-time-X > o is this trunk sourcing calls from a low distribution of ANI but >a different distribution of CallerID > o is this trunk sourcing calls from unmatched (as a percent of >total) ANI/CallerID > >I would think you could make similar correlations across the >destinations on your phone-network: > o Is there one ANI or CallerID talking to 'all' (a bunch, more >than X of type Y customer end point) of my endpoints? > o are there implausible callerid being used? (lots of 'NPA-NXX >matches destination, yet from a very different geography?) > >I imagine that with the number of calls here, this is just a splunk >correlation away from successful identification and then disabling of >these nuisance calls... >I imagine this doesn't need 'shaken' nor 'stir', but DOES take: "a >whiff of a care" on the part of the carrier(s), right? >Maybe they don't actually care about this problem until they are >'forced' to care about it by their regulating body? >'shaken' and 'stir' may not do anything at all useful for the >problem, >but they do make it appear that the carriers care about the >problem... >I'm certain that they know there are problems. The 5 items above >can't >be 'new and novel' concepts ... since this is basically 'logs >analysis' that any security engineer worth their salt does as a >matter >of course daily, right? > >-chris
