If we are sending digits (either DTMF, MF, or SF) to the called channel
after receiving progress or a wink, and the callee hangs up before we
have finished sending it digits, there are several problems that can ensue:
* If the callee hung up without answering, the calling channel would
hang up and not continue in the dialplan.
* If the callee *did* answer before hanging up, the answer was never
passed through to the caller, since this gets "eaten" by the various
digit streaming functions and is never processed by app_dial.
This is generally an edge case that occurs due to some kind of signaling
failure, but to better handle this:
* Set to_answer to 0 to prevent hangup on the exit path, just like other
parts of wait_for_answer.
* Better document this usage of to_answer.
* If the channel did answer while it was receiving digits, manually
answer the calling channel before we abort. The call would not continue
in the dialplan anyways (either before or after this fix), but technically
the call was answered, so the CDRs should probably reflect that, and this
mirrors the behavior of calls which normally do not continue.
Resolves: #1915
UserNote: If a called channel sends progress or wink and the caller begins
sending digits but the callee answers and then hangs up before digit
sending can finish, the call is now answered before being disconnected.
If the callee hangs up without answering, the call now continues in
the dialplan.
fe149119af