Bug #129
Superfecta possibly skips Trunk Provided data source under some circumstances
| Status: | Closed | Start: | 05/26/2009 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assigned to: | - | % Done: | 100% |
|
| Category: | - | |||
| Target version: | Caller ID Superfecta v 2.1.X Maintenance Releases |
Description
[quote]
even though I am specifying the lookups in this order:
- Asterisk Phonebook
- PhoneSpamFilter
- Trunk Provided
- Superfecta Cache
- (....the rest....)
It is apparently in some cases skipping the "Trunk Provided" name. For example, I saw one come in today where the Noop statement was showing that the provider was sending the name in the form LASTNAME,FIRST and yet the Caller ID being sent to the end user is First Lastname, which it probably got from AnyWho (this is a number that's definitely NOT in the Asterisk Phonebook).
This is the "sanitized" CLI output from that call (actual numbers and name changed):
[code]
-- Executing [12345678900@custom-from-trunk:1] NoOp("SIP/12345678900-b7d14960", "Caller ID name received from provider is LASTNAME,FIRST") in new stack
-- Executing [12345678900@custom-from-trunk:2] GotoIf("SIP/12345678900-b7d14960", "0?noplusatstart") in new stack
-- Executing [12345678900@custom-from-trunk:3] NoOp("SIP/12345678900-b7d14960", "Changing Caller ID number from +18005551212 to 18005551212") in new stack
-- Executing [12345678900@custom-from-trunk:4] Set("SIP/12345678900-b7d14960", "CALLERID=18005551212") in new stack
-- Executing [12345678900@custom-from-trunk:5] Goto("SIP/12345678900-b7d14960", "from-trunk|12345678900|1") in new stack
-- Goto (from-trunk,12345678900,1)
-- Executing [12345678900@from-trunk:1] Set("SIP/12345678900-b7d14960", "__FROM_DID=12345678900") in new stack
-- Executing [12345678900@from-trunk:2] Gosub("SIP/12345678900-b7d14960", "cidlookup|cidlookup_6|1") in new stack
-- Executing [cidlookup_6@cidlookup:1] Set("SIP/12345678900-b7d14960", "CALLERID=First Lastname") in new stack
[/code]
Note that I had already stripped the + before Superfecta ever got hold of the number, so that should not be the issue.
I will also mention that for now I'm only using the basic set of "Ignore keywords": unknown, wireless, toll free, unlisted
I am wondering if the comma in the Caller ID name might for some reason be causing Superfecta to think the name is invalid? That's just a shot in the dark, though.
History
Updated by tshif over 2 years ago
More input from lost trunk
Okay, I think I have figured it out, and it has nothing to do with the comma. In source-Trunk_Provided.php it looks like you are first executing a core show channels, trying to pick out the right one, and then doing a core show channel (Channel ID) to get the extended info. Which, at least on my box, works great on some trunks, but not others. The reason is that in some cases the full channel identifier gets truncated in the core show channels display, therefore the core show channel doesn't work!
AND THE SOLUTION IS...
Use "core show channels concise" instead. It does NOT truncate the channel identifier. It uses ! characters as separators between fields, like this:
SIP/12345678900-b7d15628!ivr-2!s!12!Up!BackGround!custom/ivr-main!8005551212!!3!7!(None)
I don't know what the fields all are, but I'm guessing that the first (and maybe the eighth) are the two that would be significant to the operation of this module. The beauty is that you don't get any head or tail information lines that have to be knocked out. So you could just look at the eighth field of each line until you match the caller ID number, then use the channel identifier in the first field (which is NOT truncated) as the argument of your core show channel to get the name.
Updated by jacobsj over 2 years ago
- Status changed from New to Closed
- % Done changed from 0 to 100
PBXiaF forum user Lost Trunk has tested the fix and verified that it's working on his machine and it works on mine as well.