CNAM for toll-free numbers [telecom]

I have toll-free numbers from a couple of SIP providers. When I call someone and send those numbers as my outgoing CID, I want the name that shows up to be my company name. My SIP providers say that they cannot set Caller ID Name (CNAM) for toll-free numbers, and as far as I can tell, the CNAM database does not even support toll-free numbers. Yet when I get calls from other companies with toll-free numbers, sometimes I do see a company name (though usually not). So it must be possible. Does anyone know how to do this?

My initial guess was to try and get my number listed with toll-free directory services, as someone once mentioned that some carriers may get CNAM info from that database. I tried that; I got a TF number from Verizon, and I also tried listing another TF number with AT&T directory services. Neither worked.

Thanks! Tas

Reply to
Tas Dienes
Loading thread data ...

I ran into an issue like this at one of my employer's offices. Our outgoing numeric caller ID (not a toll free number) was being displayed with four different CNAMs (Calling Names) depending on which local phone company the recipient of each call was subscribed to. Three of the four names were wrong, and one of the wrong ones was the name of a competitor.

In the process of troubleshooting this issue, we found that:

- Each local phone company that receives an incoming call from another company (whether local or long distance) receives only the 10-digit calling number, but no name. The name must be looked up in a Line Information Database (LIDB) to which the recipient's phone company subscribes.

- There are on the order of 10 LIDB providers in North America including Neustar, TNS, Qwest, Sprint and Verisign. The ones that have familiar phone company names are run by corporate divisions separate from the named phone company. They all sell LIDB services to both related and unrelated phone companies.

- LIDB includes many data items besides CNAM, such as address, name of the local company that serves that number, whether it's a cell or pay phone, calling card validation info and other data that phone companies can't operate without.

- Our Verizon business rep advised me to call each end-user phone company and open a trouble ticket to request that the CNAM be fixed. It took about 2 months of research and poking around by a staffer, but the three phone companies with wrong CNAMs eventually started to display the correct CNAM. We had to check by calling out to sample recipients and having them report back what name they saw.

- Unlike the public DNS system used on the internet, there is apparently no authoritative "name server" which will always return the customer's desired CNAM for a given number and could therefore be used to keep all other LIDB's up to date.

- Since we were not the customer who saw the wrong name displayed, we had to open a trouble ticket as a non-customer, which means the far-end phone company could not verify who we were through an account number and had to trust us to give the right CNAM. The three companies displaying the wrong name (which were corrected) were Cablevision Optimum, Verizon, and Service Electric (cable).

- CNAMs are only displayed by the recipient's landline phone company (could be copper, fiber optic, cable TV or internet VoIP provider). You can't test for correct CNAM by calling to a cell phone. Cell phones use the address book inside the phone to come up with a name and don't use LIDB for that purpose.

I'll bet the same applies when the originating 10-digit number is toll-free. You would need to find the names of each affected end-user phone company that is displaying the wrong name and have each one fix it. Then wait, and test it. You will have no idea if a rural independent in western Nebraska is dispalying the wrong name until someone there complains to you. Overall, not a stellar system.

Greg Monti, New York, NY

***** Moderator's Note *****

While there isn't a "root" LIDB database, the accuracy of the existing ones could be dramatically improved by allowing them to copy some items from the E911 database. For obvious reasons, the E911 database providers pay a lot of attention to getting address info correct, and those fields could be combined with information from other databases to improve LIDB quality.

For less obvious reasons, the E911 database isn't currently available for this purpose. Any sharing plan would have to include "Trusted and Neutral Third Party" data escrow to prevent divulging the locations of battered women's shelters, etc.

Bill Horne Moderator

Reply to
Greg Monti

--- On Thu, 12/30/10, Moderator wrote as a Moderator's note:

Many customers haved reasons, good or not, for having their names and numbers not disclosed. The E911 database lists all these because the emergency responders need to know. The general public does not.

There is a note in most phone books that the E911 PSAP will have all the informations about you, and if you want it not to be disclosed to them call the agency on its listed number, not 911.

Wes Leatherock

Reply to
Wes Leatherock

There are 10 major sources of potential error? Hideous.

I would be very greatful if would post the list, with contacts, for comment.

Of course there is an authoritative answer. It comes from the database the network the call originated on contributes records to. Linking this with our recent discussion of Local Number Portability, this mess is an example of how things go wrong when information isn't managed neutrally. Also, there is an economic incentive to supply incorrect information on incoming calls.

If the called party and the calling party are on two different networks, there is a charge to the inbound network to dip the database of a foreign network. To avoid this charge, the inbound network instead dips the database you described instead. On that database, records don't expire at times they should, like changing to another network per Local Number Portability, change of billing name, or disconnect then reconnect at a new service location with an unrelated subscriber.

The incentive isn't "Supply accurate information," but "Supply something, anything at all."

Now, one hopes that a telephone company, no matter how many subscribers it has, is capable of updating its own database with information about changes in billing name, disconnects, telephone numbers donated to Local Number Portability, and new connections/numbers received from LNP, even if foreign networks refuse to pay for the dip. But I know of instances in which a business's outbound trunks displayed CNAM of individuals (presumably the subscribers who once had those lines) when calling numbers belonging to the same telephone company.

But the economic incentives are all wrong. Why should the called party's network be charged for CNAM? CNAM should be forwarded from the originating network for all calls as in enhancement to ANI. I think ANI is the correct model, not DNS.

I'm amazed that, as a nonsubscriber, you were even able to open a ticket. When I went through this with Comcast, the ticket had to be opened under the account of a Digital Voice subscriber.

Of course, the correct solution to the error is to expire the record, which forces a new dip the database of the originating record. But these companies avoid paying for these dips like the plague, even though it's got to cost them more to perform their own data entry than the fraction of a cent the dip costs.

Except that toll-free numbers CANNOT originate calls. A toll-free number either points to a group of inbound trunks or an ordinary phone line, which gives its own number in ANI. Outbound calls from a call center originate on outbound trunks with their own ANI.

"Root" is the database of the originating network, where all such information should originate from. An E911 database is a third party, and shouldn't be used as source.

Reply to
Adam H. Kerman

I frequently get junk calls and legitimate calls where the Caller ID is a toll-free number, e.g., 800-xxx-xxxx. Are these numbers spoofed?


Reply to

ANI is not Caller ID. The ANI is the billing info, which is very hard to spoof, provided by the originating telco switch, and points to the actual line that made the call. Caller ID can be set by terminal equipment, particularly if the call originates over ISDN or VoIP, and can be set to more or less whatever the caller wants. There are perfectly legitimate reasons for ANI and CNID not to match, with the most common being that the ANI is a PBX trunk, and the CNID is the number of the extension.

If the 800-xxx-xxxx really is a number at which you can call back the person who's calling, I suppose I wouldn't describe it as spoofed. And they're doing you a favor, since approximately 100% of calls with

800 CNID are calls you can safely not answer.

Regards, John Levine,, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail.

formatting link

Reply to
John Levine

John, would you PLEASE stop cutting attribution lines?

I agree with what you wrote, but I do get calls returned from companies I do business with in which the 800 number is shown and the employee leaving the message has nearly zero telephone etiquette. If they are returning my call with the answer to my question, then at least knowing what city they called from may be helpful. ANI gives me that; a substituted number in Caller ID does not. Otherwise, I call back, give my account number, and the person finds no notes on the account, so I have the fun of repeating everything.

I've found that the telephone company has the worst telephone etiquette of all, and they have no concept of leaving the number of their extension.

***** Moderator's Note *****


Excuse _me_ sir: I'll have you know that I *am* a high school graduate!

Bill Horne Moderator

Reply to
Adam H. Kerman

I found a solution: listing the number with AT&T directory services white pages. It just took a few days for the change to kick in. I have not done extensive testing, but it works with at least a couple of carriers. The AT&T number to call to do this is 800-496-4430 (just finding that took a while).

Reply to
Tas Dienes Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.