asterisk users - May 2005 - CNAM lookup: new method for Caller ID Name delivery

[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" <tracyg@accudatatech.com>  [sales contact]
   "Kevin Nguyen" <kevinn@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

> 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)
>
I wonder if CallerID names are in the public domain or considered 
public record?

John Todd wrote:
> [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" <tracyg@accudatatech.com>  [sales contact]
>   "Kevin Nguyen" <kevinn@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
> _______________________________________________
> Asterisk-Users mailing list
> Asterisk-Users@lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-users
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>
If it isn't agiast there agement, I would happy setup a "resale"
server
for this just as you said, and probly at the prces you listed, I will 
look into this  abit more later today.

Only thing I use my asterisk server for, for the most part is a few 
select hpones (very low usages), but my exist customers (who have a 
higher volune), or people just wanting todo CNAM look ups could befit 
from this.