Summary:ASTERISK-13270: No CallerID in CDR when inbound calls from Dahdi are routed to Queue
Reporter:Alisher (licedey)Labels:
Date Opened:2008-12-24 12:29:40.000-0600Date Closed:2011-06-07 14:03:00
Versions:Frequency of
Description:Recently I upgraded server to Asterisk 1.4.22 with latest Dahdi drivers. I am using TDM400P card. The incoming CallerID is not stored in the CDR. I can see the CallerID on the telephone, but in the cdr there are only blank fields for src. When I route calls directly to SIP, with Dial application, the CallerID is stored correctly. Also no problems for incomming VOIP calls. The problem disappeared after I downgraded system back to Asterisk 1.4.20 and Zaptel. Probably new chan_dahdi broke the queue.


Currently,with Dial application, for each call asterisk stores two lines in the cdr. One is with correct CallerID and another with blank fields. When inbound call from dahdi routed to queue, in the cdr there is only one line with blank fields.

"","","s","internals-group_1","SIP/3001-09ca4e28","","","","2008-12-25 02:59:37","","2008-12-25 02:59:50","13","0","NO ANSWER","DOCUMENTATION","","1230141577.1",""

"01022240074","01022240074","s","from-group_1","DAHDI/1-1","SIP/3001-09ca4e28","Dial","SIP/3001@3001|120|ftThHkKEwWr","2008-12-25 02:59:36","","2008-12-25 02:59:50","14","0","NO ANSWER","DOCUMENTATION","","1230141576.0","1230141576.0"

"","","s","internals-group_1","SIP/3001","","","","2008-12-25 03:01:48","","2008-12-25 03:01:59","11","0","NO ANSWER","DOCUMENTATION","","1230141708.3",""
Comments:By: Leif Madsen (lmadsen) 2009-04-21 21:43:12

I've assigned this to mnicholson to see if he can determine why this might be happening, but if it is not directly related to the CDRs, and rather is some nuance with chan_dahdi that you can't figure out in a timely manner, please set this back to 'New'.

By: Matthew Nicholson (mnicholson) 2009-05-14 17:58:49


I am spending my time with higher priority issues right now.  Please assign to someone else.

By: Jason Parker (jparker) 2009-06-25 11:38:36

This looks very similar to ASTERISK-13064.  Per the comments there, I am going to suspend this.  I suspect that this has also been fixed already.

If you can reproduce with the latest version of 1.4, please reopen this issue.  You might also consider testing the patches that were uploaded to ASTERISK-13064.