On Thu, Jul 11, 2019 at 2:35 PM Michael Thomas <mike@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@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?)