I have been running the beta 9 of 1.6 for some time and not had any issues with the CDR event being sent back to the AMI interface. However, when I install rc6 I am always getting a “NO ANSWER” disposition for calls that are “ANSWERED”. Anyone have any ideas why? Is there a new configuration I need to set up?
Thanks,
Scott
Having the same issue here with 1.6.0.1, have you found any solutions yet?
No, not yet. I am still runniing beta 9. I was thinking of giving 1.6.1-rc1 a try but haven’t got around to it. If you find an answer please post it.
So I’ve created a workaround for this in 1.6.0.6 but it probably isn’t ideal and it would be nice to have some of the developers weigh in at this point. So my original problem that was after an Originate call, regardless of the disposition the CDR came back as “NO ANSWER”.
I made an update to manager.c in the function fast_originate (which is fine for me since I am doing an async call); after the call to manager_event for the OriginateResponse I added the following line (and obviously a recompile of asterisk is required):
if (reason == 4) {
ast_cdr_answer(chan->cdr);
}
Now I have not studied the code well enough to know if this is a reasonable place for this but, as I said, it seems to have solved my immediate problem with no negative impacts. So when the originate response has a reason of 4 (answered) I make a call to ast_cdr_answer to do the same. For my testing this seems to be working perfect. My CDR records are correctly identified as “ANSWERED” or “NO ANSWER”.
Cheers.
Have you tried posting this as a bug? This is definetely a bug even if it affects only certain people (maybe because of our dialplan or whatsoever) but whatever the cause is… it can’t label an answered call as unanswered.
maybe if we post it as a bug then the developers will have a serious look at the issue??? let me know if you open a ticket so I can confirm it…
Vito
I’m pretty sure that some cases of not getting ANSWERED have been tagged onto one of the many CDR related issues on the bug tracker.