[VoiceOps] Bizarre CNAM behavior

[Carlos Alvarez]

I recently had a conversation with Hiya and one of the other ID/filter
companies (who insists that I don't identify them).  It was pretty
educational.  I had a customer who was having odd but "related" CNAM
results.  Meaning that they would have a DID with an executive's name
attached, which had never been set, or the names of their customers.  What
was explained to me is that these systems use a lot of pattern matching and
data crawling to try to ID the call.  Basically you can request that they
fix erroneous data, and they might, but it may happen again.

You can pay Hiya (an amount I can't disclose but it's insanely high IMO)
and the others to let you set your desired data in their web UI, or to
allow you to send in CSVs with the desired data.  Hiya has a web UI,
another I can't name uses CSV, and two others are mostly unresponsive and
useless.

My guess on the books is that it's similar to the exec names for my
customer.  Something crawled the site and found a PR for a book title, and
"call the publisher at 602-555-1212 for more information."  Now it took the
title and made it the CNAM.

I can't decide if the "pay to fix your info" is extortion, or just the way
to accomplish a little bit of user protection right now.


On Wed, Feb 12, 2020 at 2:24 PM Jay Hennigan <jay at west.net> wrote:

> We have a customer that is a book publishing house. For the most part
> when they make outgoing calls the displayed CNAM is correct. However,
> for some (but apparently not all) calls they make to Verizon and
> T-Mobile cell phones the CNAM for their main number displays as the
> title of a book that they first published in 2006. This is one of
> thousands of book titles that they have published. Obviously they have
> never had a telephone account associated with this title.
>
> If I had to guess, I'd say that some entity is crawling the web for
> phone numbers, attempting to associate the results with names, and
> selling this as CNAM data.
>
> Trying to get this fixed is going down a rabbit hole. Has anyone else
> seen something like this and if so were you able to resolve it? We've
> frequently run into stale data from cacheing and I know that CNAM issues
> are hit-and-miss but this is pretty weird.
>
> --
> Jay Hennigan - jay at west.net
> Network Engineering - CCIE #7880
> 503 897-8550 - WB6RDV
> _______________________________________________
> 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/20200212/fc0a3964/attachment.htm>