Review Board 1.7.16

Fix the 'd' option to Dial and add the ability to not mark a CDR answered in the Answer application

Review Request #145 - Created Feb. 6, 2009 and submitted

Mark Michelson
Issue 14164 was opened because the 'd' option to Dial was not working correctly when using SIP phones. I determined that the reason was that rfc2833 or inband DTMF would not be able to flow without an RTP session set up. While it would be nice if this could be solved by setting up early media between the endpoint and Asterisk, my experience in working on this (plus a nudge from file, thanks!) showed that phones do not seem willing to pass DTMF until the call has been answered. Thus the simple fix for this bug was to answer the channel in app_dial if we see that the OPT_DTMF_EXIT flag is set.

I got to thinking, though, and realized that this method could result in unexpected CDR dispositions and answer times, so I modified __ast_answer to take a third parameter. This third parameter is a boolean which tells if we should mark the CDR as answered or not. Since I was adding this to the __ast_answer function, I realized that this could be a handy option to have in the dialplan for the Answer application. So I modified builtin_answer in pbx.c to take an optional "nocdr" argument which will not mark the CDR answered if set.

My plan, assuming this is approved, is to place everything except for the modification of builtin_answer into all branches of Asterisk. The modification to builtin_answer will be trunk-only since it is a new feature.
My testing included making sure that the CDR was not marked answered until the call was actually answered by the remote party when used after an answer that does not mark the CDR answered. My testing also included making sure the 'd' option to Dial worked. It did.
Review request changed
Updated (Feb. 7, 2009, 7:13 a.m.)
Updated app_dictate and app_waitforsilence to only call ast_answer in the case that the channel is not already up.
Ship it!
Posted (Feb. 11, 2009, 7:14 a.m.)
looks good, nice work! runs on a server provided by Digium, Inc. and uses bandwidth donated to the open source Asterisk community by API Digital Communications in Huntsville, AL USA.
Please report problems with this site to