Caller ID Superfecta

I have a code fix working on my system only for canpages411 to remove the leading space of CNAM:

existing line 113:
$name = ucwords(strtolower($first¹." ".$last¹));

proposed line 113:
$name = trim(ucwords(strtolower($first¹." ".$last¹)));

For 411.ca I can't seem to get rid of the space no matter what I try. Also if the 411.ca lookup source fails to find a match and cascades to another source, then the CNAM data from the other source (which ordinarily works fine) also has a leading space.

I see the lines of code were mangled, and I got the line number wrong and I also messed up the name of lookup source; let's try again. This is a proposed fix for CANPAGES lookup source to remove the leading space from CNAM

existing line 123
$name = ucwords(strtolower($first[1]." ".$last[1]));

proposed line 123
$name = trim(ucwords(strtolower($first[1]." ".$last[1])));

Spoke too soon, space seems to come and go. At this point I can't narrow down any particular cause. Has anyone else seen this behavior?

The leading space in CNAM seems to come and go, I have no idea at this point if it is even Superfecta related. In case anyone thinks I am dreaming it up, here is an excerpt from my FreePBX log:

6.   2010-09-15  21:48:06  IAX2/voipm  902897xxxx  " Visual Voice" <902897xxxx> 
8.   2010-09-15  21:47:00  Zap/2-1     897xxxx     "L Gaetz"       <897xxxx>
10.  2010-09-15  21:37:47  IAX2/voipm  902897xxxx  " Visual Voice" <902897xxxx>
12.  2010-09-15  21:37:13  SIP/lgaetz  902897xxxx  " Visual Voice" <902897xxxx>
14.  2010-09-15  21:36:09  IAX2/voipm  902897xxxx  " Visual Voice" <902897xxxx>
16.  2010-09-15  21:35:32  SIP/lgaetz  902897xxxx  " Visual Voice" <902897xxxx>
18.  2010-09-15  21:33:20  IAX2/voipm  902897xxxx  " Visual Voice" <902897xxxx>
20.  2010-09-15  21:32:42  IAX2/voipm  902897xxxx  " L Gaetz"      <902897xxxx>
22.  2010-09-15  21:30:51  SIP/lgaetz  902897xxxx  "Visual Voice"  <902897xxxx>
24.  2010-09-15  21:30:11  IAX2/voipm  902897xxxx  "Visual Voice"  <902897xxxx>

Over the course of 18 minutes, repeated calls from the same number to the same PBX over different trunks. The cache was turned off for this test. CNAM="Visual Voice" comes from Canpages lookup, and CNAM="L Gaetz" comes from trunk provided. Both sources have an initial space or not, with no pattern that I can see. Between calls I tweaked the order of the lookup sources which explains why CNAM changes between calls.

Ok, it took a lot of playing but I can reproduce this issue repeatedly now.

1) If ca411 is the first lookup source, the CNAM will always have an initial space, even if the ca411 lookup fails and the CNAM comes from another source in the same scheme or in a subsequent scheme, CNAM will always have a leading space

2) If ca411 is in the same scheme with other lookup sources, even if the other sources are called BEFORE ca411 and are successful, the CNAM will have a leading space

At this point, the only way I can prevent a leading space from occurring from ANY source is to have ca411 in a scheme by itself and have it be the last scheme.

Do the CNAM in question get returned have any special characters in it (when received from the source)? Such as special accent characters?

Returned results don't have any special characters that I can see, this happens on every can411 lookup.

There is a thread on PIAF forums with user complaining about exact symptom, but may not be ca411 related.

[[http://pbxinaflash.com/forum/showthread.php?t=8234]]

lgaetz - Id like to build a beta copy of 2.2.4 for you to test for this problem. WOuld you be willing?

Yes, tho it has to be tested on my prodution machine, so I won't necessarily get comments back to you immediately, it will probably be several days. Just drop a note in this thread or PM me on PIAF with upgrade instructions.

Havnt forgotten. Just polishing up the 2.2.4 pre before attaching it to this ticket for testing.

I uploaded a new source file for seaching http://www.whitepages.ca/ which is ripped off line for line from source-White_Pages.php. My initial testing is promising, much faster lookups than 411.ca and no issues with leading space. This source may render 411.ca obsolete.

whitepages.ca has become my favorite lookup source for Canadian numbers. I have tested quite a bit on canadian residential and business numbers and they are all there. I have not tested with many US numbers but if it uses the same database as the US whitepages.com, then it will be a very good source indeed.

I think I did not follow the proper naming convention when I uploaded it.

What do you view as the next desired action item for this case?

The only useful information in this thread is in post#6. The bug is still outstanding, I can't find the problem, and I have given up using this lookup source anyway. You should prob not close the issue, but set to low priority, someone may feel compelled to look into this at some point in the future

This is an open bug. Any devs interested - please access.

1. the lookup source passes the CNAM back to callerid.php with no space, no funny characters. The leading space is NOT part of the $caller_id string generated by sourceCan411.php. Even if the space was passed as part of $caller_id it would be stripped off by callerid.php
2. I don't see anywhere in the ca411 lookup source code where an extra space is being printed, this seeemed the most likely suspect.
3. This lookup source is a bit more complicated than most other ones. It first does get_url_contents from the original URL then searches that string for another URL and does another get_url_contents again to search for the CNAM. I know of no other lookup source that does this, and it is possible that this double call to that function is responsible for the space.
4. This is one of two lookup sources with digits in the file name in case that matters

Do you have a number than can reliably show this bug?

Please try out r288. Also, do you have anything filled in under "CID Prefix URL"?

John, I sent some phone number and screen shots to your gmail address. I never use anything for CID prefix URL. Will try r288 now.

r288 does not solve this issue

I see you are playing with the get_url_contents function. I always wondered why the author(s) defined that function instead of using the PHP get_file_contents which can accept a URL

Please give r289 a try.

Success! r289 fixes the issue. Ready for QA testing

So I am clear on what the problem was, was it just an extra space after the ?> atathe very end of the file?

That appears to be it. Sorry not to make the comments on r289 more descriptive.

QS: Passed. No ill effects from using this version.
Accepted for live Update.