[VoiceOps] Bizarre CNAM behavior

Calvin E. calvine at gmail.com
Wed Feb 12 18:55:20 EST 2020


Neustar is also directly responsible for unexpected CNAM in some cases.
When Neustar transitioned from their "Targus" database to the current
"Titan" database, they imported the data from Targus to Titan as
"supplemental" data, distinct from what the TN owners configure as the
"primary" record. If there is no primary record to answer a TN dip, the
supplemental data is used instead. However, this supplemental data is not
shown in the normal primary record reporting, so carriers don't know there
is supplemental data unless they ask Neustar specifically.

On Wed, Feb 12, 2020 at 1:34 PM Carlos Alvarez <caalvarez at gmail.com> wrote:

> 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
>>
> _______________________________________________
> 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/1a2def29/attachment.htm>


More information about the VoiceOps mailing list