Multiple CDR entries + missing CDR data

I recently upgraded from Fedora 19 to Fedora 23, resulting in an Asterisk upgrade from 11.5.1-2 to 13.3.2-1

I largely copied my asterisk config from the old server to the new one, only editing the config where things were broken.

I have an entry in extensions.conf that will make all extensions ring, as follows…
exten => allHome,1,System(/usr/share/asterisk/scripts/incoming.sh ${CALLERID(num)})
exten => allHome,n,Dial(SIP/201&SIP/202&SIP/203&SIP/204&SIP/205&SIP/206&SIP/207&SIP/208&SIP/209,20)
exten => allHome,n,Voicemail(100,us)
exten => allHome,n,Congestion

This has the effect of making all phones ring, and the first to pick up will get the call.
With the older version of Asterisk, this would result in one CDR entry listing only the extension that picked up. With the newer version of Asterisk this is resulting in 9 CDR entries (one per extension) with the succesful one listed as “ANSWERED” and the rest as “NO ANSWER”.

Is there any way to change this back to the behaviour of Asterisk 11.5.1 (one CDR entry only) ?

Secondly, I have some additional entries in extensions.conf to record additional information about the call (IP addresses, jitter, codecs, etc) which are executed at the end of each call, however the database only ends up with this information for internal calls (incoming and outgoing calls have these fields blank in the DB, despite the fact that I can see the data being populated in the asterisk console).

For example, an internal call comes up with the following in the asterisk console…
– Executing [h@users:1] NoOp(“SIP/207-00000015”, ““extended CDR””) in new stack
– Executing [h@users:2] Set(“SIP/207-00000015”, “CDR(hangupcause)=0”) in new stack
– Executing [h@users:3] Set(“SIP/207-00000015”, “CDR(peerip)=192.168.129.4”) in new stack
– Executing [h@users:4] Set(“SIP/207-00000015”, “CDR(recvip)=192.168.129.4”) in new stack
– Executing [h@users:5] Set(“SIP/207-00000015”, “CDR(from)=sip:207@xyz.xyz.xyz”) in new stack
– Executing [h@users:6] Set(“SIP/207-00000015”, “CDR(uri)=sip:207@192.168.129.4:5061”) in new stack
– Executing [h@users:7] Set(“SIP/207-00000015”, “CDR(useragent)=Linksys/SPA2102-5.2.12”) in new stack
– Executing [h@users:8] Set(“SIP/207-00000015”, “CDR(codec1)=ulaw”) in new stack
– Executing [h@users:9] Set(“SIP/207-00000015”, “CDR(codec2)=ulaw”) in new stack
– Executing [h@users:10] Set(“SIP/207-00000015”, “CDR(llp)=0”) in new stack
– Executing [h@users:11] Set(“SIP/207-00000015”, “CDR(rlp)=0”) in new stack
– Executing [h@users:12] Set(“SIP/207-00000015”, “CDR(ljitt)=0.000545”) in new stack
– Executing [h@users:13] Set(“SIP/207-00000015”, “CDR(rjitt)=0.000000”) in new stack
– Executing [h@users:14] Set(“SIP/207-00000015”, “CDR(server)=4”) in new stack
And puts the following into the DB
±--------------------±------------±----±----±---------±-----------------±-----------±----------±---------±---------±--------±------------±---------±------------±----------±--------------±--------------±---------±------------±-------±-------±-----------------------±------------±--------------±--------------±-------------------------±---------------------------±----±----±---------±---------±-------+
| start | clid | src | dst | dcontext | channel | dstchannel | lastapp | lastdata | duration | billsec | disposition | amaflags | accountcode | userfield | uniqueid | linkedid | sequence | peeraccount | codec1 | codec2 | useragent | hangupcause | peerip | recvip | from | uri | llp | rlp | ljitt | rjitt | server |
±--------------------±------------±----±----±---------±-----------------±-----------±----------±---------±---------±--------±------------±---------±------------±----------±--------------±--------------±---------±------------±-------±-------±-----------------------±------------±--------------±--------------±-------------------------±---------------------------±----±----±---------±---------±-------+
| 2016-04-09 14:18:38 | “207” <207> | 207 | 111 | users | SIP/207-00000015 | | SayDigits | 207 | 1 | 1 | ANSWERED | 3 | | | 1460175518.36 | 1460175518.36 | 28 | | ulaw | ulaw | Linksys/SPA2102-5.2.12 | 0 | 192.168.129.4 | 192.168.129.4 | sip:207@xyz.xyz.xyz | sip:207@192.168.129.4:5061 | 0 | 0 | 0.000545 | 0.000000 | 4 |
±--------------------±------------±----±----±---------±-----------------±-----------±----------±---------±---------±--------±------------±---------±------------±----------±--------------±--------------±---------±------------±-------±-------±-----------------------±------------±--------------±--------------±-------------------------±---------------------------±----±----±---------±---------±-------+

When I make an external call, it shows the following in the console at the end…
– Executing [h@users:1] NoOp(“SIP/207-00000018”, ““extended CDR””) in new stack
– Executing [h@users:2] Set(“SIP/207-00000018”, “CDR(hangupcause)=16”) in new stack
– Executing [h@users:3] Set(“SIP/207-00000018”, “CDR(peerip)=192.168.129.4”) in new stack
– Executing [h@users:4] Set(“SIP/207-00000018”, “CDR(recvip)=192.168.129.4”) in new stack
– Executing [h@users:5] Set(“SIP/207-00000018”, “CDR(from)=sip:207@xyz.xyz.xyz”) in new stack
– Executing [h@users:6] Set(“SIP/207-00000018”, “CDR(uri)=sip:207@192.168.129.4:5061”) in new stack
– Executing [h@users:7] Set(“SIP/207-00000018”, “CDR(useragent)=Linksys/SPA2102-5.2.12”) in new stack
– Executing [h@users:8] Set(“SIP/207-00000018”, “CDR(codec1)=ulaw”) in new stack
– Executing [h@users:9] Set(“SIP/207-00000018”, “CDR(codec2)=ulaw”) in new stack
– Executing [h@users:10] Set(“SIP/207-00000018”, “CDR(llp)=0”) in new stack
– Executing [h@users:11] Set(“SIP/207-00000018”, “CDR(rlp)=0”) in new stack
– Executing [h@users:12] Set(“SIP/207-00000018”, “CDR(ljitt)=0.000579”) in new stack
– Executing [h@users:13] Set(“SIP/207-00000018”, “CDR(rjitt)=0.000000”) in new stack
– Executing [h@users:14] Set(“SIP/207-00000018”, “CDR(server)=4”) in new stack
However the DB entry is missing this information…
±--------------------±------------±----±------------±---------±-----------------±-----------------------±--------±-------------------------±---------±--------±------------±---------±------------±----------±--------------±--------------±---------±------------±-------±-------±----------±------------±-------±-------±-----±----±----±----±------±------±-------+
| start | clid | src | dst | dcontext | channel | dstchannel | lastapp | lastdata | duration | billsec | disposition | amaflags | accountcode | userfield | uniqueid | linkedid | sequence | peeraccount | codec1 | codec2 | useragent | hangupcause | peerip | recvip | from | uri | llp | rlp | ljitt | rjitt | server |
±--------------------±------------±----±------------±---------±-----------------±-----------------------±--------±-------------------------±---------±--------±------------±---------±------------±----------±--------------±--------------±---------±------------±-------±-------±----------±------------±-------±-------±-----±----±----±----±------±------±-------+
| 2016-04-09 14:21:30 | “207” <207> | 207 | 01800150436 | users | SIP/207-00000018 | SIP/MyNetFone-00000019 | Dial | SIP/MyNetFone/1800150436 | 6 | 4 | ANSWERED | 3 | | | 1460175690.41 | 1460175690.41 | 31 | | | | | | | | | | | | | | NULL |
±--------------------±------------±----±------------±---------±-----------------±-----------------------±--------±-------------------------±---------±--------±------------±---------±------------±----------±--------------±--------------±---------±------------±-------±-------±----------±------------±-------±-------±-----±----±----±----±------±------±-------+

Does anyone know why only some calls have the full data recorded in the DB?

Thank you.

CDR support in 13 was completely rewritten and a specification[1] was written. This specification ensures that all legs are reflected. It’s not possible to change this. As for your variable problem that is being tracked on the issue tracker[2].

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+CDR+Specification
[2] https://issues.asterisk.org/jira/browse/ASTERISK-25458

1 Like

Hi,

try using variable ${ANSWEREDTIME} in your dial plan instead of using billsec.
that’ll give you the amount of seconds the call lasted for the channel that was answered.