Caller ID Superfecta

The auto refill of the default words is by design. Its there so people have a way back if they delete their defaults accidentily. Perhpas it would be better if we changed that behaviour to a check mark box that when enabled will repopulate the defaults. If you want to write and add that - I would have no objection to a change like that.

If this behavior is by design, that is fine. Being new to this module, I found it to be a unusual thing to see, but I can't imagine a situation when you need to remove the default keywords. I was only trying to clear the field for testing purposes.

Well - just because we did it that way on purpose - doesnt mean thats the BEST way to do it. We should think about chnaging it so the user CAN save a null set vs. having to have data there. I do lilke the idea of having the ability to reset defaults also. Like I said - open to change on this.

This is the important part of this ticket, and I have sent email to jjacobs to ask him to look at this code - it was his baby and nobody knows this part of the code better than him.

The first source on my lookup list is "trunk provided" with the default list of ignore words. 
This works fine, until I add any CID Rules, after that my Zap Trunk Provided CID name is ignored
(or stripped) and attempted to be replaced with the remaining lookup sources in the list.

He has said it wont be before the end of the month when he can stop by and try and figure it out for us.

Certainly - any one can take a stab at it before then - Jeremy wasn't able to guarantee he'd be able to help.

I have a functional work around for this problem. I had to create two schemes, the first I have only "Trunk Provided" selected with all defaults, no CID rules nothing. It then cascades to the second scheme which has all the other lookup sources and my CID rules.

Lorne

Would you be willing to document that in the documents section?

I have recently opened up the User Wiki for this module as well - perhaps that would be better than the document area. Either way - how about a litte write up on "How to get the most out of Schemes" or something to that effect?

I added something to the bottom of this document Was that what you had in mind? Feel free to reword it so it makes sense.

I made some minor cosmetic changes - and yeah that looks pretty good. At least we have it noted so that is someone runs afould of this - we have a place to point them for help.

Thanks for the write up!

What do you think of takeing a crack at the source-file to see if you can change that behaviour of re-establishing the defaults when the filed is cleared. May add a check mark box that when clicked causes that behaviour instead?

Theres another ticket for another project that is also working on similar but different aspects of the data source functionality - you might find it interesting

Another issue possibly unrelated to the above, but I include here anyway.

Most of my calls come in over Zap trunks via an OpenVOX 4 port FXO card. Incoming CID can be either 7 digits (NXXXXXX) or 11 digits (1NXXNXXXXXX). I prefer to keep the trunk provided CID names when possible so my first Superfecta Scheme has "Trunk Provided" as the only lookup source. I have the default ignore keywords as well as one more "(N/A)" without quotes. It seemed to be working, but after a week or so of usage, I realize that Superfecta is not keeping the Trunk Provided CID name when the incoming CID is 11 digits. It is working OK for the 7 digit CID. It has taken a while to realize this because most 11 digit incoming calls do not pass a CID name, but some do, and these ones are no longer being reported. All incoming 11 digit calls cascade to the second Superfecta scheme and attempt to find the Name using other lookup sources.

Ignore the previous comment to this one, it is unrelated to this issue.

I have determined the reason why the trunk provided lookup source cannot be used with CID rules. The trunk provided lookup source first parses the output of "core show channels concise" and looks for the channel that matches exactly the CID number passed to it from superfecta. If superfecta alters the CID number via the rules, then it will never match the CID that is parsed from "core show channels concise".

I committed a change to the source that added a note to the CID rules help warning about using the lookup source with CID rules that change the number.

Got a code fix working on my machine now which seems to work. I will be testing over the next few days and will report back when I have finished. As usual I add here for comments from others, tho nowadays it seems like I am talking to myself:

in file /bin/source-Trunk_Provided.php lines 42 & 64

existing code:

42    if(substr($thenumber,-10) == substr($this_chan_array[7],-10))
.
.
.
64    if ($provided_caller_id == $thenumber)

proposed:

42    if ($thenumber_orig == $this_chan_array[7])
.
.
.
64    if ($provided_caller_id == $thenumber_orig)

I just noticed in the first few lines of source-Trunk_Provided.php this line:

//this file is designed to be used as an include that is part of a loop.
//If a valid match is found, it should give $caller_id a value
//available variables for use are: $thenumber
//retreive website contents using get_url_contents($url);

In the fix proposed above, I suggest abandoning matching to the variable $number and using $number_orig instead. Is this a violation of the policies set forth for this module?

I would appreciate hearing from others - what doyou think of this fix?

In the absence of feedback from others, Id like to consider this. The most important thing is that it doesnt break anything else in the module - or the way folks use it.

What has your experience been with it over the last 10 days or so? Is it testing well?

lgaetz wrote:

I committed a change to the source that added a note to the CID rules help warning about using the lookup source with CID rules that change the number.

Which revision (committ) was this? r264?

yes r264

I have been using this latest modification:

line 42:  (if ($thenumber_orig == $this_chan_array[7])

since Sept 21. Over that time I have received about 500 calls, about half of them have valid trunk provided CNAM and I have no issues. CID is an even mix of 7 digits and 11 digits. Unfortunately all my calls come in over ZAP trunks, so I can't test with voip trunks, but I helped Jake with this lookup source a few weeks ago and he volunteered to help test in future. Perhaps you can press him into service as a guinea pig.

lgaetz wrote:

I have been using this latest modification:

line 42:  (if ($thenumber_orig == $this_chan_array[7])

since Sept 21. Over that time I have received about 500 calls, about half of them have valid trunk provided CNAM and I have no issues. CID is an even mix of 7 digits and 11 digits. Unfortunately all my calls come in over ZAP trunks, so I can't test with voip trunks, but I helped Jake with this lookup source a few weeks ago and he volunteered to help test in future. Perhaps you can press him into service as a guinea pig.

Ok - The current svn file has this in line 42:

 
 if(substr($thenumber,-10) == substr($this_chan_array[7],-10))

This was your last update - so - which way have you been testing it?

Go ahead and commit to SVN the version your testing with - Im getting ready to build a prerelease module for testing. :)

Also, the current SVN version was just released to Live Update - was that a mistake on my part?

Changes committed. see r268

Excellent - thank you.

Just so there is no (less!) confusion:

The change that you just distributed via live update was to address the problems with 11 digit incoming numbers (Issue #349), and was tested by both me and by Jake independantly. Between the two of us we have I think tested most cases for 7 digit, 10 digit and 11 digit CID lenghts and we are happy with it.

The second change that I committed in r268 is meant to addres this issue, the inability to use CID rules with this lookup source. I have been testing this one for 9 days and it works great for me on my ZAP trunks using 7 and 11 digit incoming numbers. I just now did a handfull of tests with 10 digit voip numbers and it works fine for that too. It has not been tested by anyone else at this point.

lgaetz, after having tested it for a time, do you feel this should be released to live update?

Works fine for me over two weeks now, but it would be nice to have at least one independant tester before it hits the street. Were there no volunteers?

lgaetz, I'm still suffering confusion. Please - check whats in the repository and make sure that its the way its supposed to be. If this is a data source update - (Truck_Provided) again, would you make sure the current live update version is exactly as you intended?

If yes, then go ahead and close this ticket. I'm still confused, and not sure if this case has been handled. If it IS a data source related ticket, set the version to Superfecta Data Sources. THANKS.

Just did the live update and am now using the new version of trunk provided successfully. Issue closed.

D'oh! Issue was closed and update was was released, then I found the warning in $source_desc that still said that it could not be used with CID rules. I have commited change to repository to fix.