Feature #150

Add a check of the number format/area code before querring the online database

Added by patrick_elx over 2 years ago. Updated over 2 years ago.

Status:Closed Start:06/23/2009
Priority:Normal Due date:
Assigned to:- % Done:

100%

Category:-
Target version:Caller ID Superfecta v 2.1.X Maintenance Releases

Description

in each source specific module, I would like to have a simple check at the beginning of the module to see if it does worth trying the lookup.

For instance, no need to query the Canadian only source database when the area code is not from Canada.
Also it can check if the number of digit is valid or not.

All of that should be done in each source lookup agi.

That will help save a few second of lookup.


Related issues

related to Caller ID Superfecta - Feature #167: Add a check of the number format/area code before querring the online database for source canpages.ca Closed 06/23/2009

History

Updated by tshif over 2 years ago

  • Status changed from New to Feedback

It seems to me that this decision would be invisible to the module. If the data source itself determined that its not worth running the lookup, it could immediately pass a "Invalid For Area" Message as a failed lookup. This way it wouldn't stop the the next source from trying.

It would reduce overall latency as well. This seems like a good idea to me.

Updated by patrick_elx over 2 years ago

  • % Done changed from 0 to 30

I've modified the source-Canpagesca in rev 109 to check if it's a valid CAN npa.
If not, it just replies not found and save 1 second of lookup time.

Could be upgraded with a not valid database to have a finer feedback to the main module, but I would suggest a more extensive rewriting of the main code with the option in ticket # 151

Updated by tshif over 2 years ago

  • Target version changed from Caller ID Superfecta - Future Versions to Caller ID Superfecta v 2.1.X Maintenance Releases

Is there an advantage to putting this in all the lookup sources- not just canpages?

Updated by patrick_elx over 2 years ago

I think each module should check its own information.
Some modules are valid for US and CAN, some only for 800 numbers, some only for US, some for other countries etc...
It will be too difficult to have all the scenarii in the main module. It's easier for each source lookup developer to put all its specifics in the same unit.

Updated by tshif over 2 years ago

Are you willing to convert the existing modules to this new format - self checking npa's?

Updated by patrick_elx over 2 years ago

I can try to update the other modules.
I'm just not sure of what should be the filter for each source.
Do you already have a list of what can do each of them? US, CAN, 800, other country...

Updated by tshif over 2 years ago

NerdUno - do you know of a place to get such information?

Updated by patrick_elx over 2 years ago

To make the module more international, I would suggest that we removed from the main php the npa and tollfree check to move them in each source module instead.

It will unfortunately be duplicated in each module using a npa format, but the delay for each check is negligible.

Updated by tshif over 2 years ago

Ward has responded that he knows of no source for this data.

Updated by jacobsj over 2 years ago

I'm working on converting some of the other sources, but I need to do some testing. As I don't live in Canada, can someone provide me with a valid Canadian phone number to do some checking with. If all else fails, I'll just try to find a random company in Canada and use their phone number to test with.

I agree that the valid number checking should be done in the source files, that way sources for Europe and co-exist with sources for the US. Right now with NPA and number length checking in the main module, non US/Canadian numbers break the module.

Updated by jacobsj over 2 years ago

  • Status changed from Feedback to Resolved
  • % Done changed from 30 to 90

Please check my work, but this should be implemented on all the sources that can use number format validation.

Updated by jacobsj over 2 years ago

  • Status changed from Resolved to Closed
  • % Done changed from 90 to 100

Also available in: Atom PDF