Caller ID Superfecta

This strange character only is visible in the database and when using the superfectacache from other programs (like I did). It doesn't seem to affect the display on any phone I used so far (softphone, cisco 7940, grandstream 2000). So my opinion is to release it regardless if we can fix this or not.

Look at it in debug - does the character not show up in the debug entries for you?

Im not comfortable with that ... yet. I would like a better understanding of what potential impact this decision could have.

This case duplicates 203.

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.

I still have issue with the latest version.
It seems that the debug window accommodate really well another charset, but the phones and asterix not.

For instance the following number is fine on debug, but not in the CLID: 3287268044 (plenty of spaces in front of the number despite a trim, wrong charset)

We need to find a way in the curl call to find the charset (easy to do with a curl -L) and then to apply the appropriate charset transform to utf-8

It will then solve a lot of issues with any source and be better than the mandatory transform that we put for the other sources previously.

Also to help debug external calls (that are not acting like the debug function) I am following this procedure:
- create a superfecta scheme that you will put in first position, make it with a filter for the DID: 'test'
- create an inbound route for the DID 'test' that will call superfecta as CID lookup and send it to an IVR, extension or whatever you want
- allow anonymous sip calls (maybe not needed depending on your distrib)
- Use zoiper (no account need to be set) and dial sip:TheNumberYouWantToTest@IPAddressOfAsterisk/test

It will emulate a sip call from your DID test from TheNumberYouWantToTest
Look in the CLI what's happening during the call.

Charset used on the infobel site is 'Windows-1252' (see bug 207), but I can't get it converted well (used iconv).
The plenty spaces are probably from an empty line at the end of the file outside the php-code, or from a bad conversion from dos2unix or vice versa (I develop mostly on linux, but uploaded it from windows). I had troubles before having those spaces andit turned out to be one of these ..

The devs like this case - so its open again - :-)

check rev 203. I think I solved 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.)

Reservations: Does this solve the superfecta_cache bug aspect of the problem? #212 and #207? DO these interact with this fix?

There were a few cache problems:
- the number send to the cache was modified by our source lookup (bug #212). It was fixed by Zorka.
- the number send to cache contained chr 160. Fixed in rev 203. The number send to cache is either ASCII extended (when $charsetIA5 is false) or ASCII standard (when $charsetIA5 is true).
- the number sent to cache (when $charsetIA5 is false) could contain html_entities. Fixed in rev 204. ASCII extended is filtered for html_entities. (Solve problem seen for instance with Hitta_SE and Open79XX that could contain such characters)

Briliant work - truly. To normalize the character sets depending on the destination was extreemly smart; Treating each delivery channel (debug, phone CID) as seperate was very wise!

Superfecta wouldn't have been nearly as truly world-wide-friendly without these last changes. I beleive it was important to wait for this to be fixed (as it seems you have) for 2.2.2 - since this is the release that is supposed to make us almost worldwide CID scheme fool proof. (I should NEVER say that out loud. The code will hear me and make me sorry!)

Nice work!