Caller ID Superfecta

Looks good right now. We're probably going to change the way individual sources that need source specific customization (ie username, passwords, keys, etc.) are handled by the UI and during running, so we'll need to change this code to update it.

This code has passed standards - and can be released in its present form as a manual add-on (since it requires manual editing.) We will include it in version 2.1.0 since the new architecture will support the user interface portion of the authentication this source requires.

The information returned to the debug interface for this data source does not detect and pass back failures due to account restrictions (I.E., wrong API code (rejected), or "Low Account Balance") - which could be important to debugging end users.

Dev - please size task for returning this type of data to the debug interface.

I am unsure how to have anything return for the debug screen as VoIPCNAM only returns a blank page without any error.

Any ideas?

Having not used this provider source before, does VoIPCNAM return a blank result in both the case of an empty account and a wrong API key?

Is this different from a case where no CID information can be found by VoIPCNAM?

michaelruge wrote:

I am unsure how to have anything return for the debug screen as VoIPCNAM only returns a blank page without any error.

Any ideas?
You probably already thought of this - but did you look at the source code for the "blank" page? Maybe there really is some hidden fields or data being returned we could use as a signal of certain conditions.

What does it return if the number is not found? Is that BLANK also? Or if your account (like mine) is underfunded so results are not returned - they must return some error status for these eventualities somewhere.... or am I assuming they are smarter than they really are? <g>

michaelruge - Would you be willing to send an email to them as an account holder asking them these questions?

I did check the source and they do not provide anything.

I threw everything I could think of to their Query script (http://query.voipcnam.com/query.php) and all it does is return a blank page if there is an error. My account is funded as I utilize them as a backup to my other methods in the Superfecta addon.

I will send an email to them and asking them about this and let you know what I hear back.

Excellent thank you Michael!

I believe we could release this data source as it now stands - but I would like to be able to better reflect these various states in the debug if they are available from the API.

This speaks to a possibly bigger issue.

I suggest that as we move to support more sites that require some form of authentication, that a portion of them will be "for-pay" sites. These site, hopefully, will normally return some status information such as "account expired", "underfunded", etc.

Q: Does the current architecture support the ability for the new data source scripts to be coded to recognize these extended account info kinds of errors, and return those statuses through debug? (Since they are not likely to be http errors as the current debug info receives - although I suppose they could be.)

Jeremy - I guess you'd be in the best position to provide this answer - please share you thoughts as well.

I send an email to VoIPCNAM. I will let you know when I hear back from them.

Any debug information that the source script designer wants to provide, they should be able to.

All they have to do is print the information to the screen after checking that the script is running in debug mode ala:
if($deubg) {
print 'I felt like printing this line because I\'m ultra-cool<br>';
}

The source script designer can really decide for themselves how verbose they want the debug information to be. The only debug output that is done for them already are scripts that are using the curl function.

Ok - we wont hold the release for this. If we find a way to include better status info (if they respond to Michaels email for example) in time - well add it to his contributed script, otherwise well go with it as it sits now. Either way, I say we use it.

Here is the email I received back from VoIPCNAM:

Hi Michael!

There is a way to get this status information, but unfortunately it's a system-wide setting (for the time being). This means that I can enable the feedback messages system wide for debugging if necessary, but not long term.

The next release of our system software will include several enhancements, including this kind of feature.

Have you encountered any errors that you have been unable to resolve?

Regards, Brett VoIPCNAM.com

Great info Michael. So we are going with this code as it stands - and well look back at them when they get their API expansions online in the future. Thanks everyone for participating.