diff options
| author | twilson <twilson@f38db490-d61c-443f-a65b-d21fe96a405b> | 2010-10-13 22:45:15 +0000 |
|---|---|---|
| committer | twilson <twilson@f38db490-d61c-443f-a65b-d21fe96a405b> | 2010-10-13 22:45:15 +0000 |
| commit | b3c12812faaad238df01669752b1a0878da56998 (patch) | |
| tree | 79f1116d9d84895ba0f23902aca2916bb426cfe2 /channels | |
| parent | 5aa6e27f96b52de56bc4dda9c0d0cec8dcd11158 (diff) | |
Don't ignore frames that have been queued when softhangup'd
When an outgoing call is answered and hung up by the far end *very* quickly, we
may not read any frames and therefor end up with a call that displays the wrong
disposition/DIALSTATUS. The reason is because ast_queue_hangup() immediately
sets the _softhangup flag on the channel and then queues the HANGUP control
frame, but __ast_read refuses to read any frames if ast_check_hangup() indicates
that a hangup request has been made (which it will if _softhangup is set). So,
we end up losing control frames.
This change makes __ast_read continue to read frames even if a soft hangup has
been requested. It queues a hangup frame to make sure that __ast_read() will
still eventually return NULL.
Much thanks to David Vossel for all of the reviews, discussion, and help!
(closes issue #16946)
Reported by: davidw
Review: https://reviewboard.asterisk.org/r/740/
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@291577 f38db490-d61c-443f-a65b-d21fe96a405b
Diffstat (limited to 'channels')
0 files changed, 0 insertions, 0 deletions