SHAKEN/STIR Robocall Summit - July 11 2019 at FCC

Thu Jul 11 19:03:52 UTC 2019

On Thu, Jul 11, 2019 at 2:35 PM Michael Thomas <mike at mtcc.com> wrote:
>
> So I have a meta-question about all of this. Why in 2019 are we still
> using telephone numbers as the primary identifier? It's a pretty sip-py
> world these days, even on mobile phones with wifi calling, I assume. It
> seems like this problem would be more tractable if callerid was a last
> resort rather than a first resort.

yes! I bet that if you provided some form of 'identity' to the caller
and permitted the callee to verify that data upon call setup... you'd
get further along.
there could  even be an ecosystem of services which callees could
subscribe to in order to report reputation and have that be used to
influence call completions over time...

if only there were such systems in existence already... if only some
form of proof of concept existed?

> Mike
>
>
> On 7/11/19 10:18 AM, Christopher Morrow wrote:
> > On Thu, Jul 11, 2019 at 12:00 PM Paul Timmins <paul at telcodata.us> wrote:
> >> Chris it would be trivial for this to be fixed, nearly overnight, by
> >> creating some liability on the part of carriers for illicit use of
> >> caller ID data on behalf of their customers.
> > 'illicit use of caller id' - how is caller-id being illicitly used though?
> > I don't think it's against the law to say a different 'callerid' in the call
> >   session, practically every actual call center does this, right?
> >
> >> But the carriers don't want that, so now we have to create tons of
> >> technical half solutions to solve a problem that would be neatly solved
> >> by carriers.
> > logs analysis and 'netflow' (CDR trolling, really) would be nearly free for
> > them, implementing actions based on the data / outcomes of that
> > analysis at near-real-time would also be nearly free...
> >
> > but sure, we can do a bunch of this other stuff too...  My sort  of solution
> > has actually got proven track record though?
> >
> > -chris
> >
> >> On 7/11/19 12:09 AM, Christopher Morrow wrote:
> >>> 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?)