app_dial: Properly handle callee hangup while sending digits.#1916
Merged
github-actions[bot] merged 1 commit intoMay 12, 2026
Merged
Conversation
Contributor
Author
|
cherry-pick-to: 23 |
github-actions
Bot
added
pr-submit-testing-in-progress
pr-submit-tests-passed
and removed
pr-submit-testing-in-progress
labels
|
Workflow Check completed successfully |
InterLinked1
force-pushed
the
master-issue-1915
branch
from
c40aaa3 to
41a6d3d
Compare
github-actions
Bot
added
pr-submit-testing-in-progress
pr-submit-tests-failed
and removed
pr-submit-tests-passed
pr-submit-testing-in-progress
labels
|
Workflow Check failed |
jcolp
requested changes
May 11, 2026
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: asterisk#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.
InterLinked1
force-pushed
the
master-issue-1915
branch
from
41a6d3d to
606b226
Compare
github-actions
Bot
added
pr-submit-testing-in-progress
pr-submit-tests-failed
and removed
pr-submit-tests-failed
pr-submit-testing-in-progress
labels
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
github-actions
Bot
added
the
has-pr-checklist
|
Workflow Check failed |
github-actions
Bot
removed
the
has-pr-checklist
jcolp
approved these changes
May 12, 2026
github-actions
Bot
added
cherry-pick-testing-in-progress
|
Workflow CPCheck failed |
github-actions
Bot
added
pre-merge-testing-in-progress
pre-merge-checks-passed
merge-in-progress
and removed
merge-approved
pre-merge-testing-in-progress
labels
|
Successfully merged to branch master and cherry-picked to ["23","22","20"] |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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:
hang up and not continue in the dialplan.
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:
parts of wait_for_answer.
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.