Caller ID Made Simple | Hacker News Reader

Caller ID Made Simple

rdegges.com

152 pointsnantes64 comments

Randall,

This looks remarkably easy to use. Just a small tip: On opencname's home page, you suggest users try the following API call:

  $ curl https://api.opencnam.com/v1/phone/2024561111
  US GOVERNMENT

I tried it and received a different result:

  $ curl https://api.opencnam.com/v1/phone/2024561111
  DIST OF COLUMBI

Perhaps you should update your home page to reflect this?

Hey Adley, thanks for the comment! I'll update the page shortly.

When I tried it I got this:

"Sorry, not implemented yet. Please append "?format=json" to your URL."

When I did that it worked.

You must have tried it in a web browser. Using curl sends different request headers. When you are using a web browser, it asks for text/html. Try ?format=text

It must be Tastypie thingy. Nice to see Django-powered site.

This is the first API that I've encountered that works with cellphone numbers. I can see this being integrated into Android for incoming calls from unknown cellphone numbers.

My thoughts exactly! I easily get less than 60 calls per hour so this would be perfect. Interestingly, the caller ID for my number is tied to the first owner of my account before it was transferred to me (which happened many years ago).

An Android app is currently in development, and will be released free of charge. We are having an issue, however, because non-GSM carriers rarely allow data transmissions during a voice call, including the ringing state of incoming calls.

Even a lookup app would be handy for seeing missed calls, etc.

Give us a few more weeks of development for this, and it will be ready. The current working title of the Android app is "FreeCallerID," but we may change this before launch. Just look for the Round OpenCNAM logo to make sure you found the right app.

Need beta testers?

It should still work while on Wi-Fi, correct? That would still be an improvement over the status quo (no caller ID).

Yes, the in-development Android app does work when the Android device is on wifi.

Without Voice-over-LTE, I'm not sure how you're going to get around it. It's not a carrier limitation, it's a limitation of CDMA radios and implementations.

The best you could do is do the query after the call, and cache it locally if the caller calls again.

Well, I've often used my mobile internet at the same time as talking in the phone (although it fails sometimes (and I don't have LTE)).

Also, there are many applications in the market that does exactly this. I haven't installed any of them since I basically don't trust anyone with "read/write contacts" and "full internet access" at the same time (perfectly valid permissions for apps like this, but that doesn't mean I trust them).

A search for "vemringde" gives you four apps that targets Sweden specifically (so they are probably quite useless outside of Sweden), one of them mentions that it only works while having a 3G connection.

Not over CDMA without the proper extension that enables simultaneous use of data and voice. And even then, the OS/driver stack has to implement it properly. I can assure you, even on LTE, it does not work on my Android 4.0.4 device.

It's only an issue for non-GSM phones i.e. CDMA phones used in the US and parts of Asia. CDMA does not allow data and voice to run at once over the same radio, while GSM does. Since LTE is an entirely IP network, voice can be run over it like any other IP network. Current phones/carriers do not support it though, but there's some talk that it will be introduced in the next year or so.

Can anybody tell me more about the cdma and gsm usage ratio in the US?

Two of the major carriers in the US use CDMA (Verizon and Sprint), while the other two major carriers use GSM (T-Mobile and AT&T). I'm having some trouble finding recent market share numbers for them, but it's mostly half and half.

Seriously? Three people went through and mass downvoted my posts in this thread? Why? Why-oh-why?

This shouldn't be an issue with LTE, right?

Please make it open source as well as free of charge! It could be a useful example to extend.

We actually have this on iOS: it is called IntelliID; that said, the concept doesn't work very well, because by the time the phone gets its data connection warm enough and is able to do the minimum two round-trips over the incredibly high-latency cellular connection to get the data (and have to wait for the lookup itself, which seems to be an entire half a second for this API), you are pretty much fighting with the call timing out and going to voicemail.

I would ONLY be willing to use this if it returned better data than Twilio's CNAM lookups (costs $0.01) for a cheaper overall price.

So far, I've tested my number, and a few others, that I know have CNAM data that this service only provides a STATE for. Hopefully it will get better but it's not there yet for me.

I tried 6 numbers of friends and only one returned a result. Are many numbers not callerid-able, or is the api just bogged down?

I had to refresh the page a few seconds later to get my ID information to show up after the first request.

Hi there. So, I'm the author of this article. Anyhow, for our free-tier users we don't provide realtime lookups.

Basically, we'll only return a result if we have a caller ID in our cache. So, if you get a 404 (no output), then try again a few seconds later after we've had time to do the lookup via our backend.

Sorry about that! Realtime lookups are currently restricted to API key users only.

You might make this more obvious. Also, you might state how to distinguish between "sorry we need more time to look this up" and an actual 404 or error.

HTTP code 202 Accepted seems appropriate for this (http://en.wikipedia.org/wiki/List_of_HTTP_status_codes)

504 Gateway Timeout would be the obvious one, since if I'm reading this correctly it's essentially a timeout of zero; 5xx status codes are indicative of retriability later on.

But I think that sort of performance would make the free tier essentially worthless. “All you have to do is hit our API endpoint, and BAM, you get results back.” Except you really don't. Analogy: a caching DNS resolver that returned an instant SERVFAIL if the results weren't already in memory wouldn't be considered acceptable even for demo purposes anywhere that I've seen.

Hey premchai21, thanks for the feedback! You're completely right. I'll be making some adjustments to the way this operates over the coming days to make things much simpler.

Thanks for taking the time to check us out!

> But I think that sort of performance would make the free tier essentially worthless.

Not at all. It lets you try out the API, figure out if it works for you, and get back "best effort" results. That seems perfect for a free tier.

I suppose being able to try out the API on the software level is useful, yes. I'm not sure how one is supposed to figure out whether results are likely to be good enough for a given application if they're so unpredictably degraded. I do suspect my perception is being colored by the website text, as quoted above.

I guess I disagree here (but who doesn't with HTTP status codes...). I try to reserve 5XX codes for actual errors. In this case, no error occurred, the response is just delayed.

Hey mike, thanks for the feedback. I'll be working on this tomorrow to get a fix out.

After all the feedback here, I realize how crazy it is to be returning a 404.

Thanks for checking us out, and thanks for the feedback!

Is there any way to tell the difference between "try again" and "no data available"?

And you should have made this MUCH more visible on your website. I initially tried your service, got zero results and dismissed it as a failure.

Only after reading here did I realize your service actually does work, I just have to try each query twice.

Hey ars, thanks for the feedback! After reading the comments here on HN (which are incredibly valuable), I'll be making those changes ASAP.

Sorry for the confusion, but thanks again for the feedback. I greatly appreciate it.

I can see why you want to do this, but this just makes people send 2 requests instead of 1 for each number they look up.

Not sure if this is the better way.

> you can't get something working within 5 minutes of vising our website, we've failed our mission.

It took me five minutes on the website ... and I had to come back to HN and read the comments to get this working. Don't want to be discouraging, but maybe you should provide this information in the blog/website otherwise you have failed (for me atleast).

Hey samirahmed, thanks for the comment! I'll definitely be updating my blog post and improving the documentation on the website.

Appreciate the feedback.

This is awesome! I had a couple of free hours, so I hacked together a little Ruby app that validates a telephone number and full name pair. This could be used for sign-up security, etc. You can find the repo here: https://github.com/EricR/sinatra-cnam-lookup

For what it's worth, and for all those asking questions about Canadian numbers, caller id name is handled differently in Canada than in the states. When a carrier sends an outgoing call, they include the caller id name in the SS7 IAM (Initial Message), unlike the states where the receiving carrier has to do a database lookup on the number to retrieve the name. This likely explains why a lot of Canadian numbers are not returning any results, or incorrect results.

Personally, I think the Canadian system of including the name in the IAM works a lot better than having to do a DB lookup.

I believe this is also the case for public switched telephone network in the US. On a landline, the name and number of the calling party is transferred by Bell 202 and a lot of phones will display this information.

This discussion is about how the name is delivered to the telephone company being called, not from that company to your phone. In the US, the calling telephone company sends the number, the called company looks it up in a database, then sends the name they get to your phone. Everything but the delivery to the phone takes place over the SS7 network.

I wonder if the providers of this service have thought about crowd-sourcing the caller-id information, like http://mrnumber.com/ whose free tier harvests number->name mapping from users address books...

This would not work because of the sheer number of users who store nicknames, particularly uncomplimentary ones. Would you want your name displaying as "that douchebag" or "bar slut"?

I definitely find it interesting.

As somehow it pulls up my (not) apparently unlisted home phone; also, it pulls up family members names for cellphones which are under my name on the contract.

So I am definitely interested in finding out where this data is being taken from?

Hey krrose27, we basically pull the information from a variety of sources, all publicly available. If we can get the caller ID name information, then it means any call made from those numbers to a caller ID capable phone (with caller ID service) will be able to see it also.

This may be common knowledge but in the browser address bar do https://api.opencnam.com/v1/phone/2024561111?format=text

I've wondered why twilio doesn't have this feature. Good stuff!

They do provide caller id information, but not in a query interface like this. You either get the caller id information after making a call or receiving a call. Assuming you have the number configured and it costs 1 cent per lookup with the associated call.

This is cool, but fix the double request thing if you're going to have a free version...

It seems odd that it only returns a province/state when just the area code provides more information than that. Example: any (647) or (416) area code will always be from Toronto, but numbers for both just return ONTARIO.

Please make it more obvious that this only works for US phone numbers

It's not restricted to US only, but all of the NANPA. North American Numbering Plan Administration covers everywhere that uses the country code +1. This includes all of Canada, many islands and territories, and a few other exotic locations.

I just tried it for some numbers around Montreal. Apart from the delayed results issue, it works.

I just tried my home number and the name it came up with was 'Nova Scotia'. My landline provider is based in Halifax, but I'm in PEI. I'm kind of used to that, though :)

NANPA (US+Canada) only :(

There are some other small countries / territories also on NANPA, but yeah, sorry!

Well, I guess it might be useful in Jamaica.

It just says "wireless caller" for my number. Does it usually provide more information? I don't know how useful this is otherwise.

Does anyone have any insight into this? Are you'all getting better results?

That's probably an intentional choice by your carrier, many wireless carriers do that rather than provide an actual name for each number.

The drawing - is that Goemon from Rupan/Lupin series by any chance?

Reply on news.ycombinator.com