Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

CNAM for toll-free numbers [telecom]

2,976 views
Skip to first unread message

Tas Dienes

unread,
Dec 28, 2010, 4:48:28 PM12/28/10
to
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

Greg Monti

unread,
Dec 30, 2010, 10:58:22 PM12/30/10
to
On Tue, 28 Dec 2010 13:48:28 -0800 (PST), Tas Dienes
<tasd...@gmail.com> wrote:

> 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?

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
gmo...@mindspring.com


***** 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

Wes Leatherock

unread,
Dec 31, 2010, 7:37:47 PM12/31/10
to

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

> ***** 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.

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
wlea...@yahoo.com
wes...@aol.com

Adam H. Kerman

unread,
Dec 31, 2010, 9:36:42 PM12/31/10
to
Greg Monti <gmo...@mindspring.com> wrote:

>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.

There are 10 major sources of potential error? Hideous.

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

>- 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.

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.

>- 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).

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.

>- 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.

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.

>***** 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. . . .

"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.

Richard

unread,
Jan 1, 2011, 11:12:01 AM1/1/11
to
On Sat, 1 Jan 2011 02:36:42 +0000 (UTC), "Adam H. Kerman"
<a...@chinet.com> wrote:

>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.

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?

Dick

John Levine

unread,
Jan 1, 2011, 6:32:37 PM1/1/11
to
>>Except that toll-free numbers CANNOT originate calls. ...

>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?

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, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

Adam H. Kerman

unread,
Jan 2, 2011, 1:16:12 AM1/2/11
to
John Levine <jo...@iecc.com> wrote:

>>>Except that toll-free numbers CANNOT originate calls. ...

>>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?

John, would you PLEASE stop cutting attribution lines?

>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.

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 *****

Etiquette?

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

Bill Horne
Moderator

Tas Dienes

unread,
Jan 5, 2011, 7:13:28 PM1/5/11
to
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).

0 new messages