Caller ID not reporting correctly

I am running 2.3.0 with asterisk 1.4.8 and I have been noticing that caller id is not reporting correctly. What it appears to be doing is taking the name that has been assigned to an extension and applying it to the incoming call. I am not sure where this is happening or how to correct it. Does anyone have any suggestions?

Thnks,

C

I might as well be the first to say it, upgrade to the latest which is 1.4.11.

Well, that didn’t fix it.

Also, as of this morning, I was noticing that instead of recognizing the DID on incoming calls, it is reporting the incoming sip context. In the past I have defined an inbound route to go to a specific destination. In this specific case, the destination was to an IVR attendant. However, the incoming DID is not being picked up, when I look at the records, it shows that it is seeing the sip/context for that specific trunk.

Help, what do I do?

Regards,

After looking at the log files, I see this, which would seem to be a SQL error. How do I fix this?

[Sep 24 07:42:17] VERBOSE[25648] logger.c: – Executing [6782020122@from-trunk:1] Set(“SIP/from_sercom_gigi-b7d1a250”, “__FROM_DID=6782020122”) in new stack
[Sep 24 07:42:17] VERBOSE[25648] logger.c: – Executing [6782020122@from-trunk:2] Gosub(“SIP/from_sercom_gigi-b7d1a250”, “app-blacklist-check|s|1”) in new stack
[Sep 24 07:42:17] VERBOSE[25648] logger.c: – Executing [s@app-blacklist-check:1] LookupBlacklist(“SIP/from_sercom_gigi-b7d1a250”, “”) in new stack
[Sep 24 07:42:17] DEBUG[25648] db.c: Unable to find key ‘3369691895’ in family ‘blacklist’
[Sep 24 07:42:17] DEBUG[25648] db.c: Unable to find key ‘’ in family ‘blacklist’
[Sep 24 07:42:17] VERBOSE[25648] logger.c: – Executing [s@app-blacklist-check:2] GotoIf(“SIP/from_sercom_gigi-b7d1a250”, “0?blacklisted”) in new stack
[Sep 24 07:42:17] VERBOSE[25648] logger.c: – Executing [s@app-blacklist-check:3] Return(“SIP/from_sercom_gigi-b7d1a250”, “”) in new stack
[Sep 24 07:42:17] VERBOSE[25648] logger.c: – Executing [6782020122@from-trunk:3] GotoIf(“SIP/from_sercom_gigi-b7d1a250”, “0 ?cidok”) in new stack
[Sep 24 07:42:17] VERBOSE[25648] logger.c: – Executing [6782020122@from-trunk:4] Set(“SIP/from_sercom_gigi-b7d1a250”, “CALLERID(name)=3369691895”) in new stack
[Sep 24 07:42:17] VERBOSE[25648] logger.c: – Executing [6782020122@from-trunk:5] NoOp(“SIP/from_sercom_gigi-b7d1a250”, “CallerID is “3369691895” <3369691895>”) in new stack
[Sep 24 07:42:17] VERBOSE[25648] logger.c: – Executing [6782020122@from-trunk:6] Goto(“SIP/from_sercom_gigi-b7d1a250”, “ivr-2|s|1”) in new stack
[Sep 24 07:42:17] VERBOSE[25648] logger.c: – Goto (ivr-2,s,1)
[Sep 24 07:42:17] VERBOSE[25648] logger.c: – Executing [s@ivr-2:1] Set(“SIP/from_sercom_gigi-b7d1a250”, “LOOPCOUNT=0”) in new stack
[Sep 24 07:42:17] VERBOSE[25648] logger.c: – Executing [s@ivr-2:2] Set(“SIP/from_sercom_gigi-b7d1a250”, “__DIR-CONTEXT=default”) in new stack
[Sep 24 07:42:17] VERBOSE[25648] logger.c: – Executing [s@ivr-2:3] Set(“SIP/from_sercom_gigi-b7d1a250”, “_IVR_CONTEXT_ivr-2=”) in new stack
[Sep 24 07:42:17] VERBOSE[25648] logger.c: – Executing [s@ivr-2:4] Set(“SIP/from_sercom_gigi-b7d1a250”, “_IVR_CONTEXT=ivr-2”) in new stack
[Sep 24 07:42:17] VERBOSE[25648] logger.c: – Executing [s@ivr-2:5] GotoIf(“SIP/from_sercom_gigi-b7d1a250”, “0?begin”) in new stack
[Sep 24 07:42:17] VERBOSE[25648] logger.c: – Executing [s@ivr-2:6] Answer(“SIP/from_sercom_gigi-b7d1a250”, “”) in new stack
[Sep 24 07:42:17] VERBOSE[25648] logger.c: – Executing [s@ivr-2:7] Wait(“SIP/from_sercom_gigi-b7d1a250”, “1”) in new stack
[Sep 24 07:42:18] VERBOSE[25648] logger.c: – Executing [s@ivr-2:8] Set(“SIP/from_sercom_gigi-b7d1a250”, “TIMEOUT(digit)=3”) in new stack
[Sep 24 07:42:18] VERBOSE[25648] logger.c: – Digit timeout set to 3
[Sep 24 07:42:18] VERBOSE[25648] logger.c: – Executing [s@ivr-2:9] Set(“SIP/from_sercom_gigi-b7d1a250”, “TIMEOUT(response)=10”) in new stack
[Sep 24 07:42:18] VERBOSE[25648] logger.c: – Response timeout set to 10
[Sep 24 07:42:18] VERBOSE[25648] logger.c: – Executing [s@ivr-2:10] BackGround(“SIP/from_sercom_gigi-b7d1a250”, “custom/sercom-marta”) in new stack
[Sep 24 07:42:18] VERBOSE[25648] logger.c: – <SIP/from_sercom_gigi-b7d1a250> Playing ‘custom/sercom-marta’ (language ‘en’)
[Sep 24 07:42:47] VERBOSE[25648] logger.c: – Executing [s@ivr-2:11] WaitExten(“SIP/from_sercom_gigi-b7d1a250”, “|”) in new stack
[Sep 24 07:42:55] VERBOSE[25648] logger.c: == Spawn extension (ivr-2, s, 11) exited non-zero on ‘SIP/from_sercom_gigi-b7d1a250’
[Sep 24 07:42:55] VERBOSE[25648] logger.c: – Executing [h@ivr-2:1] Hangup(“SIP/from_sercom_gigi-b7d1a250”, “”) in new stack
[Sep 24 07:42:55] VERBOSE[25648] logger.c: == Spawn extension (ivr-2, h, 1) exited non-zero on ‘SIP/from_sercom_gigi-b7d1a250’
[Sep 24 07:42:55] DEBUG[25648] cdr_addon_mysql.c: cdr_mysql: inserting a CDR record.
[Sep 24 07:42:55] DEBUG[25648] cdr_addon_mysql.c: cdr_mysql: SQL command as follows: INSERT INTO cdr (calldate,clid,src,dst,dcontext,channel,dstchannel,lastapp,lastdata,duration,billsec,disposition,amaflags,accountcode,uniqueid) VALUES (‘2007-09-24 07:42:17’,’“3369691895” <3369691895>’,‘3369691895’,‘s’,‘ivr-2’, ‘SIP/from_sercom_gigi-b7d1a250’,’’,‘WaitExten’,’|’,38,38,‘ANSWERED’,3,’’,‘1190637737.129’)
[Sep 24 07:43:30] VERBOSE[25599] logger.c: == Spawn extension (macro-dial, s, 10) exited non-zero on ‘SIP/6502-b7d0ad68’ in macro ‘dial’
[Sep 24 07:43:30] VERBOSE[25599] logger.c: == Spawn extension (macro-dial, s, 10) exited non-zero on ‘SIP/6502-b7d0ad68’ in macro ‘exten-vm’
[Sep 24 07:43:30] VERBOSE[25599] logger.c: == Spawn extension (macro-dial, s, 10) exited non-zero on ‘SIP/6502-b7d0ad68’
[Sep 24 07:43:30] VERBOSE[25599] logger.c: – Executing [h@macro-dial:1] Macro(“SIP/6502-b7d0ad68”, “hangupcall”) in new stack
[Sep 24 07:43:30] VERBOSE[25599] logger.c: – Executing [s@macro-hangupcall:1] ResetCDR(“SIP/6502-b7d0ad68”, “w”) in new stack
[Sep 24 07:43:30] DEBUG[25599] cdr_addon_mysql.c: cdr_mysql: inserting a CDR record.
[Sep 24 07:43:30] DEBUG[25599] cdr_addon_mysql.c: cdr_mysql: SQL command as follows: INSERT INTO cdr (calldate,clid,src,dst,dcontext,channel,dstchannel,lastapp,lastdata,duration,billsec,disposition,amaflags,accountcode,uniqueid) VALUES (‘2007-09-24 07:39:26’,’“Curtis Taylor” <6502>’,‘6502’,‘6598’,‘from-internal’, ‘SIP/6502-b7d0ad68’,‘SIP/6598-09cee520’,‘Dial’,‘SIP/6598||tr’,244,242,‘ANSWERED’,3,’’,‘1190637566.127’)
[Sep 24 07:43:30] DEBUG[25599] app_macro.c: Executed application: ResetCDR
[Sep 24 07:43:30] VERBOSE[25599] logger.c: – Executing [s@macro-hangupcall:2] NoCDR(“SIP/6502-b7d0ad68”, “”) in new stack

I am curious as to whether the black list is causing a problem or if the database is just corrupt? I am also curious why the call is pointed to ‘s’? Is there a way to fix this?

C

bump. anyone?

I may have come across something that is affecting the clid on my system. I was reviewing all my config files and looking through all the logs. Evidently at some point in time, I had defined a specific caller id for two (2) specific zap channels. However, at this time, when I review my zapata.conf (or any variation of that) and my zaptel.conf, those definitions are not there. So, that leads me to believe that this information has been placed in the database and it is pulling that information even though it is not applicable at this time.

So, my question is this: Where is this information stored (specifically in reference to zap channels) and how to I fix this?

Thanks in advance.

C

bump

Hello There… I also have the same problem!
Every incoming calls shows a random Caller ID (frequently a name of extension number).
Any suggestion?
Cheers!

Glad to know I am not the only one. Now maybe someone else will pay attention to my question.

Cowboy47 - I don’t think it is a lack of no-one paying attention to your problem. You have what sounds like a difficult and time consuming problem to diagnose. You have provided some data but not a full picture which may be why no one has pinpointed the issue. And complex problems can take a lot of time to diagnose which is going to limit how many people are able to freely provide that.

Philippe Lindheimer - FreePBX Project Lead
http//freepbx.org - IRC #freepbx

Understood. Having said that, I recognize that this is a complex and difficult problem and I am more than willing to provide any additional information necessary to help solve it. If it were easy, I would have fixed it already. So, having said all that, if there is anything else that would help, let me know.

C

bump

bump bump

Has anyone come up with an idea or solution to this??? It still persists.