Caller ID Superfecta

I looked at the website very briefly and did a few sample reverse lookups to see how things worked. The CNAM are all in the Hebrew alphabet, I suspect callerid.php will really struggle with this. In the Serbia lookup source I noticed that non-standard ascii characters were converted to ascii, if that happens with the Hebrew it will be unreadable.

Forgot this part, english version is here: http://441il.com/reverse_lookup/phone_number/israel.html

lgaetz wrote:

I looked at the website very briefly anddid a few sample reverse lookups to see how things worked. The CNAM are all in the Hebrew alphabet, I suspect callerid.php will really struggle with this. In the Serbia lookup source I noticed that non-standard ascii characters were converted to ascii, if that happens with the Hebrew it will be unreadable.

I think that re-encode is done on purpose to limit the text sent to the phones to standard ascii, or perhaps uft8. This was done because many phones lockup if they receive any extended characters at all as part of the caller id data.

While Im sure there may be phones out there that can display the Hebrew characters as part of caller ID - it seems theres a whole lot of phones out there that would simply lock up and require aq reset when receving this non ascii text.

What do you think we should do about it? Any thoughts on a workaround?

I would be inclined to ignore the request for now. I get the feeling that some source requests are people who know of a website, and are not actual (or potential) superfecta users. I am curious to know what CID/CNAM looks like for regular phone service.

Shouldn't be too difficult to add a per scheme option of "Do not strip UTF8" -- though the ramifications of such an option would need to be spelled out clearly.

Ok - Agreed. However - as we experienced before, its not just a per source situation. It was expressed as a problem of locking up some endpoints and not others. A 'by source' control wouldn't address the 'by endpoint' issue of this type.

Perhaps it would be adequate to disclaim the use of this data source if the user has any endpoints that lockup as described. In other words, a warning about the 'unstripped' nature of the data sent via this particular source. (just thinking out loud).

To clarify:
I think it should be an option "per scheme", not per source. This way, a user would have an option of setting up a scheme that does not filter the data from any source it may be using. As it is now, the filtering happens in callerid.php, not the source, so this should be relatively easy to implement -- the more difficult part being the UI change in page.superfecta.php to add the option. However, that option would need to have a very noticeable warning on the problems it could have on your endpoints.

lgaetz wrote:

Forgot this part, english version is here: http://441il.com/reverse_lookup/phone_number/israel.html

Would a reasonable solution to get the data source working be to use the English version?

The "english" version is the english version of the website, CNAM is still returned as Hebrew.

I have never used Winunciator, does it have the ability to display foreign characters? If so, could the lookup source be written such that it restricts output to Winunciator and not the endpoints, one or the other or both at the user's preference?

Winunciator runs as a web server (mini) on the windows machine monitoring whatever port its been configured to use.

It should have access to any character sets installed in the windows platform - but I have never tested this.

It receives its data as arguments in the url. So - I have never tried to use non english chracters as part of a URL. Im not sure what happens in that case.

jkiel wrote:

Shouldn't be too difficult to add a per scheme option of "Do not strip UTF8" -- though the ramifications of such an option would need to be spelled out clearly. To clarify: I think it should be an option "per scheme", not per source. This way, a user would have an option of setting up a scheme that does not filter the data from any source it may be using. As it is now, the filtering happens in callerid.php, not the source, so this should be relatively easy to implement -- the more difficult part being the UI change in page.superfecta.php to add the option. However, that option would need to have a very noticeable warning on the problems it could have on your endpoints.

This is worth exploring. However - untill we have somone willing to test our work in the environment thats broken, is there a way for us to proceed?

tshif wrote:

until we have somone willing to test our work in the environment thats broken, is there a way for us to proceed?

Nope... it would be shooting in the dark.