i’ve been using asterisk for a few years and created a new installation, after not using asterisk for about 6 months. I normally run with the asterisk SVN ( currently 218629 ).
On my previous installation incoming dahdi (external) calls were picked up and sent to a number of extensions (3 different sip accounts).
With the new instation I am only dialing one SIP account i.e. one extension. I use CDR for call logging and monitoring missed calls, but since this new build, there is no CDR created for a ‘NO ANSWER’/unanswered call. I use cdr_mysql to an MYSQL DB.
Is this something that has changed with the current CDR logging; I noticed a comment in the code about not creating a CDR for single channels. The ‘unanswered=yes’ or ‘unanswered=no’ in cdr.conf makes no difference.
Has anyone seen a similar issue with CDR or explain any rules regarding logging of ‘NO ANSWER’ calls ?
Sorry for my previous post, didn’t read well…if you have “unanswered=yes” it should log the unanswered calls, it works for me with * 1.4.25.1, so I would check issues.asterisk.org to see if there is something about.
Discovered that calls that were not answered, as the caller hungup, are now being set with a DIALSTATUS=CANCEL.
this functions as per the documentation that if the caller hangs up before timeout is reached that the status is set as CANCEL, and therefore it appears that no CDR is created.
I read somewhere in a forum thread that in 1.6.1 the DIALSTATUS for cancel can be defaulted to NO ANSWER.
Is there a way of recording incoming changing caller hangups in CDR = rather than asterisk saying that ‘the caller has hung up’, that the ‘caller has hung up because the SIP extension being dialed did not answer with the timeout’.
I understand there is 2 ways of looking at a call being being; whether it was cancelled by the caller, or no answered by the receiving extension. Without putting a short timeout on the receiving extension, the caller can just hangup before the time-out is reached.
To workaround this I have created a ‘h’ section on the incoming context which checks the DIALSTATUS for CANCEL. If it finds CANCEL, it calls the ResetDCR(w), which causes a write of the CDR, and interestingly the DISPOSITION actually shows NO ANSWER.
I have written this solution in, as it can be annoying to see forums threads where no-one writes solutions/fixes etc for future readers to see.