| Summary: | ASTERISK-27396: Hangup not processed until voicemail timeout | ||
| Reporter: | Gary Barnes (gbarnes) | Labels: | |
| Date Opened: | 2017-11-06 12:55:16.000-0600 | Date Closed: | 2020-01-14 11:13:25.000-0600 |
| Priority: | Major | Regression? | No |
| Status: | Closed/Complete | Components: | Applications/app_record |
| Versions: | 13.7.2 15.1.0 | Frequency of Occurrence | Frequent |
| Related Issues: | |||
| Environment: | AWS Linux | Attachments: | |
| Description: | Using Asterisk 13.7.2, however the code is still the same in 15.1.0 therefore it is believed to still be an issue in 15.1 however it has yet to be verified as still active.
Call plan is set to 20 seconds (can be any real duration), once ring time expires it is set to go to voicemail, however the caller hangs up just prior to the ring time duration. There is a 0.4 second window where this issue is prevalent and easy to reproduce. Example: 20 second ring duration, caller hangs up between 19.4 - 19.7 seconds, then the call stays connected from the Asterisk perspective until the voicemail timeout occurs. The Voicemail audio file will contain only what appears to be a header, no body, and the voicemail duration is reported as the timeout length (in our case timeout is set for 600 seconds). To test I made 550 calls total, 10 concurrent calls, 1 call start per second, increasing the duration of the call by 0.1 seconds every 50th call. The failure dispersal pattern was as follows from 19.0 to 20.0 ring duration: 0, 0, 0, 9, 48, 50, 50, 44, 5, 5, 0. As you can see the failure rate between 19.4 and 19.7 seconds is 96% failure. While this situation is hard to hit, with over 25k calls processed per day we see 15 to 25 of these per day. In app_record.c, it is running an "ast_waitfor()" function on the channel for that entire duration waiting for a frame. Since the channel is down, there is no frame being sent, so it waits the full ten minutes before breaking out of the while loop. | ||
| Comments: | By: Asterisk Team (asteriskteam) 2017-11-06 12:55:16.701-0600 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. By: George Joseph (gjoseph) 2017-11-06 13:20:10.271-0600 Gary, is there any way you could try this with an actual 13.18 or 15.1 install? A lot of other things changed between 13.7 and now that could affect the problem you're describing. Given that it's not easy even for you to reproduce, we don't want to go chasing down any rabbit holes. By: Asterisk Team (asteriskteam) 2017-11-21 12:00:01.081-0600 Suspended due to lack of activity. This issue will be automatically re-opened if the reporter posts a comment. If you are not the reporter and would like this re-opened please create a new issue instead. If the new issue is related to this one a link will be created during the triage process. Further information on issue tracker usage can be found in the Asterisk Issue Guidlines [1]. [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines | ||