Missing CDR entries for outgoing calls

Asterisk Asterisk Support
1

Hello everyone,

I have strange problem with my Asterisk 1.8 on Debian Linux. For 7 extensions asterisk doesn’t write CDR entries in mysql database for outgoing calls. Extensions are both type sip (4) and dahdi (3). For incoming calls to these numbers CDR entries are generated normally - every information like callerid, duration, billsec etc. are putted correctly to database. Calls from other extensions asterisk writes proper CDR entries for incoming/outgoing calls. I checked extensions.conf, cdr.conf, cdr_mysql.conf and everything looks fine. I don’t have any idea what can be wrong in configuration. It is strange because for other extensions everything works. Has anyone idea how to solve this problem ? If you need my config files please ask for them. CDR entries are important for me because with them i can check calls duration and make billings. Thanks in advance for reply.

Regards
Panda8

2

Sounds like there’s a NoCDR()-statement soewhere in the callflow.
To be sure You should give us the CLI-output from a call from one of the extensions with missing CDR with verbosity 5 (asterisk -rvvvvv).

3

This is the CLI-output for two extensions:


  == Using SIP RTP CoS mark 5
    -- Executing [xxxxxxxxx@petit:1] Goto("SIP/petit-00000494", "48xxxxxxxxx,2") in new stack
    -- Goto (petit,48xxxxxxxxx,2)
    -- Executing [48xxxxxxxxx@petit:2] Set("SIP/petit-00000494", "CALLERID(all)=<58xxxxxxx>") in new stack
    -- Executing [48xxxxxxxxx@petit:3] Dial("SIP/petit-00000494", "sip/debile/48xxxxxxxxx,60,t") in new stack
  == Using SIP RTP CoS mark 5
    -- Called sip/debile/48xxxxxxxxx
    -- SIP/debile-00000495 is making progress passing it to SIP/petit-00000494
    -- SIP/debile-00000495 answered SIP/petit-00000494
  == Spawn extension (petit, 48xxxxxxxxx, 3) exited non-zero on 'SIP/petit-00000494'

  == Using SIP RTP CoS mark 5
    -- Executing [xxxxxxxxx@petit:1] Goto("SIP/petit-00000496", "48xxxxxxxxx,2") in new stack
    -- Goto (petit,48xxxxxxxxx,2)
    -- Executing [48xxxxxxxxx@petit:2] Set("SIP/petit-00000496", "CALLERID(all)=<58xxxxxxx>") in new stack
    -- Executing [48xxxxxxxxx@petit:3] Dial("SIP/petit-00000496", "sip/debile/48xxxxxxxxx,60,t") in new stack
  == Using SIP RTP CoS mark 5
    -- Called sip/debile/48xxxxxxxxx
    -- SIP/debile-00000497 is making progress passing it to SIP/petit-00000496
    -- SIP/debile-00000497 is making progress passing it to SIP/petit-00000496
    -- SIP/debile-00000497 answered SIP/petit-00000496
  == Spawn extension (petit, 48xxxxxxxxx, 3) exited non-zero on 'SIP/petit-00000496'

For me it looks normally, like calls from extension without this problem.

4

You are right, there’s nothing indicating a CDR would not be written here.
The only way is now to have a debug output (sometimes CDR insertion into a database may fail upin constraints in the database) using core set debug 5.
At the end of a call we should see than a debug output from the cdr module.
You may also - just for testing - enable another cdr-backend (e.g. CSV) just to check wheeter it’s a general problem or a special one related to the mysql-backend only.