Getting No Answer for Calls which are getting Answered

Hi All,
I am using asterisk release and I am making an outbound call from one asterisk box to another asterisk box that is call is made between two asterisk boxes.

But even when call is getting answered, cdr on asterisk box,from where call was initiated, is showing cdr->answer as ‘0’ and hence changing cdr->disposition from ‘Answered’ to ‘No Answer’. So can anybody explain reason for such behavior ?

However, when i was using 1.4.17 then behavior was fine, I am witnessing this problem in release.

I will appreciate timely help on this as this has become blocking for me.

Thanks & Regards
Shivam Agarwal

Technically an rc version is not a release. You need to try it again on a current release version. It appears that the current release version ( postdates your version. (As there isn’ta, it is possible that your version is the same as the real release,

Did it ever work? If it did, it may be worth raising a bug report. If it didn’t, you should post your dialplan and verbose console output here, and be prepared to provide a SIP debug trace.

Thanks David for your reply.

I looked into code and found that within “__ast_read” function,in file main/channel.c, call to ast_cdr_answer has been removed, even a comment was put for such effect.
The comment was " removed a call to ast_cdr_answer(chan->cdr) from here" .

I have tried after making a call to ast_cdr_answer and then able to get answer time. But i don’t know how safe it is.

To tell exactly where I made call to ast_cdr_answer is at the “last else” of “case for AST_FRAME_CONTROL” in function __ast_read.

Kindly help me to know whether it is fine to make such a call or not. Hoping to hear soon from you.

Thanks & Regards
Shivam Agarwal

If you are able to debug at that level, you need to track down the exact revision that made that change and look at its log comment. Normally you can do this from the log, but, if not, you should use svn blame on the trunk and/or branch versions. That will hopefully tell you why it was done.

If this is happening for a trivial dialplan and the problem is still present in the current version, and there isn’t already a report on, it is important that raise an issue to get it fixed.

If the dialplan is non-trivial, please note that it is accepted that CDRs are broken for non-trivial cases and there is a new mechanism, based on events, which is in the SVN trunk.