Bug #260
The requested URL returned error: 404 not found
| Status: | Closed | Start: | 12/08/2009 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assigned to: | tshif | % Done: | 100% |
|
| Category: | - | |||
| Target version: | Caller ID Superfecta v 2.2.4 Maintenance Release |
Description
When receiving a call from hidden number like anonymous (or any other text string for that matter) Vemringde.se and Lokaldelen.se sources are not working correctly. The output as seen below is "The requested URL returned error: 404 not found". As seen from below there is no result coming out so nothing is sent to post processing sources like the YAC which I myself use.
That does not look right. Also I got an e-mail from a user where he explained that if they get a call from anonymous number the call gets somehow stuck in their phone queue. All other normal calls works as intended. I do not have any more specifics at this time.
I will have a look myself but if anyone can see something obvious please contribute here.
Processing Default Scheme. Searching Asterisk Phonebook ... not found result took 0.0010 seconds. Searching Superfecta Cache ... not found result took 0.0018 seconds. Looking for Provided Caller ID ... CID name is the same as CID number not found result took 0.0028 seconds. Searching Telco Data ... Skipping Source - Toll Free or Non US number: result took 0.0012 seconds. Searching Hitta.se residential ... not found Searching Hitta.se business ... not found result took 0.2036 seconds. Searching Lokaldelen.se ... The requested URL returned error: 404 not found result took 0.2570 seconds. Searching Eniro.se ... not found result took 0.1322 seconds. Searching Vemringde.se ... The requested URL returned error: 404 not found result took 0.0696 seconds. result took 0.0004 seconds. result took 0.0005 seconds.
Related issues
| related to Caller ID Superfecta - Bug #237: Fatal error: Call to a member function fetchRow() on a non-object | Closed | 11/11/2009 | 08/10/2010 |
History
Updated by tshif about 2 years ago
- Status changed from New to Reviewed
- Target version set to Caller ID Superfecta Source Files
It sounds as if the phones may be getting HTM mixed up in their CID info under these circumstances. Themore info we can collect - obviously - the better we can trace this down.
Usualy start by reducing number of sources to just the ones that are not working, and determine exactly what steps are needed to reproduce problem, including phone numbers used.
Once the problem can be duplicated - we have a better chance of catching it in the act of being broken.
Updated by tshif about 2 years ago
- Status changed from Reviewed to Feedback
Updated by tshif about 2 years ago
- % Done changed from 0 to 20
I have been testing Vemringde.se and Lokaldelen.se. I am not able to replicate the failures. here are my results.
Searching Vemringde.se ... not found result took 0.8695 seconds. Searching Lokaldelen.se ... Skipping Source - Non Swedish number: 760XXXXXXX result took 0.0004 seconds.
I dont think having a sweedish number to test with would make a difference in this case - but if you have one Ill be happy to see what happenes.
Can anyone else replicate these reported failures?
Updated by nixi about 2 years ago
The problem will not come if you enter a number. Only if you enter text like "anonymous"
Updated by patrick_elx about 2 years ago
A simple test on $thenumber to reject non numerical CID number before sending it to the source is easy to do.
But do we want to do that on a source by source basis, or in general for all sources?
Also, should we allow post processing for these non numerical info? It does not make any sense to send it to the cache or other DB as there is no Caller ID number. However for winunciator or other send to only source, do we want to have the info still sent to them?
Updated by tshif about 2 years ago
patrick_elx wrote:
A simple test on $thenumber to reject non numerical CID number before sending it to the source is easy to do. But do we want to do that on a source by source basis, or in general for all sources?
We could possibly start out by adding it to the individual sources, and rev the module code to do it uniformly at the next main module update? It would be important that the two fixes don't create problems for each other.
Also, should we allow post processing for these non numerical info? It does not make any sense to send it to the cache or other DB as there is no Caller ID number. However for winunciator or other send to only source, do we want to have the info still sent to them?
I vote No, I think. non numeric caller ID Number data is technically illegal isnt it? I think Asterisk discards it if it finds it - We should emulate the same behavior.
Other folks have thoughts on this? Please - lets here them -
Updated by tshif about 2 years ago
patrick_elx wrote:
A simple test on $thenumber to reject non numerical CID number before sending it to the source is easy to do.
What approach specifically did you have in mind - Id like to get a patch out for this soon.
Updated by patrick_elx about 2 years ago
- % Done changed from 20 to 80
I've uploaded a possible fix for it. (svn rev 251)
In fact it's not because a text is sent for lookup, it's because the request is empty.
There is already a check to remove all non numeric character in the number sent for lookup, but when you have only letters the request send an empty string that cause trouble with some source.
I've just added a test to not execute any lookup if the resulting caller ID number (after our filter) has no digits.
Updated by bsau about 2 years ago
- Status changed from Feedback to Resolved
- Assigned to set to tshif
- % Done changed from 80 to 90
QS: Pass. No failures due to patch detected.
This cant be released through source live update - its in the module core. :(
Updated by tshif about 2 years ago
- Tracker changed from Support to Bug
Updated by tshif over 1 year ago
- Status changed from Resolved to Closed
- Target version changed from Caller ID Superfecta Source Files to Caller ID Superfecta - Future Versions
- % Done changed from 90 to 100
Updated by tshif over 1 year ago
- Target version changed from Caller ID Superfecta - Future Versions to Caller ID Superfecta v 2.2.4 Maintenance Release
Scheduled for build 2.2.4