John Todd
2005-05-06 03:20:54 UTC
[cross-posted to -biz and -users since it could fall into either category]
Interesting new product that has been introduced that I think some
would be interested in here (at least, those users in the United
States and perhaps Canada): CNAM delivery via IP lookup.
The problem: inbound calls on many PRI connections, and also over
many VoIP providers, do not include caller name. This means that all
you see is the caller ID number, but no name. Most PSTN lines these
days (if they are enabled with Caller ID) will also include a caller
ID name. So, you'd think that a well-configured Asterisk server
should somehow be able to deliver the same data, right?
A company called Accudata has come up with an IP-based CNAM lookup
tool. It's an HTTPS delivery method, with what I assume is XML as
the specification language. The nice part is that it really doesn't
matter what the backend looks like - Accudata has built app_getcnam
that automatically takes the 10 digit NANP number and spits back a 15
character caller name from within the Asterisk dialplan. You get the
caller ID from an inbound call (IP or PRI or any channel type as long
as it has an e.164 number associated with it) and then hand off the
${CALLERIDNUM} to this application, and get back a string with the
name. I don't have exact details on the system (see "disadvantages"
below) but it seems to be an interesting product.
Pricing:
At the "low volume" end of the scale (probably under 2000 queries
per month, but I didn't ask), the price is $0.0156 per lookup, which
is reasonable enough. I'm sure better price breaks come with volume.
Upsides:
1) They have direct Asterisk integration, using app_getcname.c as a
data method.
2) They at least are willing to talk to smaller customers who
aren't pushing millions of calls a month.
3) It's all IP - no unwarranted complexity of SS7 or other signalling.
Downsides:
1) They want you to sign an NDA before they'll discuss the methods
with you. I was not willing to sign an NDA to have an XML schema
example transmitted to me, so that was a non-starter. This really
angers me, actually - does anyone actually have a clue how many
lawyers need to get involved in an NDA, and what is it exactly that
the NDA is trying to do? NDAs are used in the USA for the most
frivolous and inane reasons. As if your competition didn't know what
you were doing? Please, let's be realistic here.
2) They have a $100 monthly minimum charge. If you only have a
billing volume of under $100, then you'll pay $100. So, if you have
under 6400 queries per month, you're paying for the honor of being
billed. This isn't that big a deal if you're an ITSP, but makes this
almost impossible for a smaller user to afford. (good opportunity for
a small reseller, especially if you are smart with caching.) I can't
say I disagree with them on this model to start, but I spent some
time doing the math for "small-time" usage, and at a $2 minimum and
50 included queries a month (and $.02 afterwards) this would make a
very nice market for a few thousand iPBX systems. Payment via Credit
Card or Paypal would be perfect; set it up once, forget about it.
However, that's not the model they chose, since they're not shooting
for the lower end of the market.
3) There may be hidden problems with the application; I haven't run
it, so I can't vouch for it.
Other notes:
The clever integrator of this application will save themselves some
lookup $ by caching the responses from the database into their own
database, along with a datestamp. Perhaps if an entry is >90 days
old, the system will re-lookup the entry in the Accudata database but
otherwise will present the memorized answer. (Hint: the caller ID's
of your inbound call pool is probably >80% redundant)
Contact information:
http://www.accudatatech.com
"Tracy Glick" <***@accudatatech.com> [sales contact]
"Kevin Nguyen" <***@accudatatech.com> [tech contact]
If anyone else has heard of an easy-to-use method for obtaining
this data via free or commercial methods, please follow-up to this
post for the archives. I don't speak for Accudata, nor am I a user
of their services, but it seems interesting so I'll pass it along to
the group.
JT
Interesting new product that has been introduced that I think some
would be interested in here (at least, those users in the United
States and perhaps Canada): CNAM delivery via IP lookup.
The problem: inbound calls on many PRI connections, and also over
many VoIP providers, do not include caller name. This means that all
you see is the caller ID number, but no name. Most PSTN lines these
days (if they are enabled with Caller ID) will also include a caller
ID name. So, you'd think that a well-configured Asterisk server
should somehow be able to deliver the same data, right?
A company called Accudata has come up with an IP-based CNAM lookup
tool. It's an HTTPS delivery method, with what I assume is XML as
the specification language. The nice part is that it really doesn't
matter what the backend looks like - Accudata has built app_getcnam
that automatically takes the 10 digit NANP number and spits back a 15
character caller name from within the Asterisk dialplan. You get the
caller ID from an inbound call (IP or PRI or any channel type as long
as it has an e.164 number associated with it) and then hand off the
${CALLERIDNUM} to this application, and get back a string with the
name. I don't have exact details on the system (see "disadvantages"
below) but it seems to be an interesting product.
Pricing:
At the "low volume" end of the scale (probably under 2000 queries
per month, but I didn't ask), the price is $0.0156 per lookup, which
is reasonable enough. I'm sure better price breaks come with volume.
Upsides:
1) They have direct Asterisk integration, using app_getcname.c as a
data method.
2) They at least are willing to talk to smaller customers who
aren't pushing millions of calls a month.
3) It's all IP - no unwarranted complexity of SS7 or other signalling.
Downsides:
1) They want you to sign an NDA before they'll discuss the methods
with you. I was not willing to sign an NDA to have an XML schema
example transmitted to me, so that was a non-starter. This really
angers me, actually - does anyone actually have a clue how many
lawyers need to get involved in an NDA, and what is it exactly that
the NDA is trying to do? NDAs are used in the USA for the most
frivolous and inane reasons. As if your competition didn't know what
you were doing? Please, let's be realistic here.
2) They have a $100 monthly minimum charge. If you only have a
billing volume of under $100, then you'll pay $100. So, if you have
under 6400 queries per month, you're paying for the honor of being
billed. This isn't that big a deal if you're an ITSP, but makes this
almost impossible for a smaller user to afford. (good opportunity for
a small reseller, especially if you are smart with caching.) I can't
say I disagree with them on this model to start, but I spent some
time doing the math for "small-time" usage, and at a $2 minimum and
50 included queries a month (and $.02 afterwards) this would make a
very nice market for a few thousand iPBX systems. Payment via Credit
Card or Paypal would be perfect; set it up once, forget about it.
However, that's not the model they chose, since they're not shooting
for the lower end of the market.
3) There may be hidden problems with the application; I haven't run
it, so I can't vouch for it.
Other notes:
The clever integrator of this application will save themselves some
lookup $ by caching the responses from the database into their own
database, along with a datestamp. Perhaps if an entry is >90 days
old, the system will re-lookup the entry in the Accudata database but
otherwise will present the memorized answer. (Hint: the caller ID's
of your inbound call pool is probably >80% redundant)
Contact information:
http://www.accudatatech.com
"Tracy Glick" <***@accudatatech.com> [sales contact]
"Kevin Nguyen" <***@accudatatech.com> [tech contact]
If anyone else has heard of an easy-to-use method for obtaining
this data via free or commercial methods, please follow-up to this
post for the archives. I don't speak for Accudata, nor am I a user
of their services, but it seems interesting so I'll pass it along to
the group.
JT