Caller ID Superfecta

I've replaced the line

1 $sname = str_replace(chr(160), ' ', $sname[1][0]);

1 $sname = $sname[1][0];

It solves this problem, but I haven't been able to find out why it was there in the first place.
In the different countries I've tried I did not notice any regression.

Please test with other countries/numbers.

updated rev 185

Interesting. Thats the á character.

The original contributor passed along to me that the original "$sname = str_replace(chr(160), ' ', $sname1⁰) was in the code because every infobel source returned the "Â" character between the first name and last name in every lookup he did.

tshif wrote:

The original contributor informs (#208) that the original "$sname = str_replace(chr(160), ' ', $sname1⁰) was in the code because every infobel source returned the "Â" character between the first name and last name in every lookup he did.

The original contributor informs (#208) that the original "$sname = str_replace(chr(160), ' ', $sname1⁰) was in the code because every infobel source returned the "Â" character between the first name and last name in every lookup he did.

Duplicate entry deleted.

All -
infobel can not return to the live update repository untill we have a handle on the spurious character issue - and exactly what it might impact. I know we all want it as a source - but we need to get it right - first.

Updated by zorka - copied from #230 which is closed as a duplicate

After patrick changed it (removing chr(160)), it doesn't show up in debug for me, nor on any of the phones we use. It is however there in the database (using webmin or sqlyog to view it) and was giving trouble with a little application we developed internally to update our CRM from the cache. But as it turns out, that application is seldom used, and Superfecta's cache was designed for that.

But I agree, we could use some more testers reporting back weither they have issues with it or not.

this page http://www.voip-info.org/wiki/view/Asterisk+func+callerid
shows that we need to limit our caller ID to only ASCII or IA5 character set.

I will try to work on a filter to make sure that will be the only table allowed.

That looks like exactly the issue we are dealing with - awesome reasearch! It will be fascinating to see your results - :-)

I've spent hours on this issue and I'm still stuck.
Here's what I think I figure out so far.

- The curl coming from the source website can have different charset. We need to transform it to utf8 for handling purpose.
Right now we force a utf8_encode in the get_url function. I tried to play with some more intelligent functions to check the charset before encoding (either a simple check for presence of utf8 before encoding or not, or more specific to treat each charset differently). I'm not satisfied with what I had right now. Still working on it but I can use help. However this part does not seem too critical right now.

- We need to split the print caller_id returned as the one we want for the debug will be in utf8 and the one for asterisk should be in ASCII. (just need to add an else in the if not debug to do the utf8_decode).

- Now what's driving me crazy with Infobel is that the utf8_decode before sending back to asterisk solves the different problem we had with this source (the chr160 and other weird issues we had), but it does add one or two lines (or special char?) in front of the CID that you can see in the CLI. First I don't know what are these char in front, and how to get rid of them.

Maybe if someone can look into a real good encoding routine from any charset to utf8, and a good decoding from utf8 to ASCII with replacement of forbidden characters..

I would also suggest that we add a checkbox option in superfecta general config to restrict caller ID to the ITU charset for legacy phones (limited ASCII without any accentuated characters). It should not be needed for SIP phones as they all accept extended ASCII, but if we do some work in this field, adding this option should not be difficult and can help users using FXS with CID.

are you sure there aren't any empty lines outside the php tags in th source ? or that the file is in the correct format (dos, unix) ? those 2 situations caused those empty lines in front of the CID in the CLI before for me

Yes that was it... Thanks
I couldn't see them when doing a direct http lookup..

How a stupid stuff can make me loose my mind.. :-(

Good, let's go back trying to debug the more important part.

uploaded SVN rev 201 (caller_id and infobel).

Please do some test and report to see if that does improve or not.
I've noticed also that my Cisco 7960 are not displaying some extended characters. It's not blocking as it does ring but replace the CID by a blank line. Will try to add some more restrictive filters later on.

check bug #215 and rev 203 that should solve this issue.

QS: Pass.

Infobel no longer returns oddball character in debug. (Nice work Patrick!)
No disturbances found in the CID presented to telephones. (This is not authorative, I never experienced this error, so I cant test for it satisfactorily.)

QS: Passed. Approved for inclusion in build 2.2.2, and posting to live update repo.

Patrick - is the current version of infobel compatible with superfecta 2.2.1 and lower? Were changes introduced in this source which require 2.2.2 and greater?