| Summary: | ASTERISK-23130: Transfer of parked call causes 100% CPU and orphaned channels | ||||||
| Reporter: | Roel van Meer (rolek) | Labels: | |||||
| Date Opened: | 2014-01-10 09:19:23.000-0600 | Date Closed: | 2018-01-02 08:30:27.000-0600 | ||||
| Priority: | Minor | Regression? | No | ||||
| Status: | Closed/Complete | Components: | Channels/chan_sip/Transfers Resources/General Resources/res_parking | ||||
| Versions: | 1.8.25.0 11.7.0 | Frequency of Occurrence | Constant | ||||
| Related Issues: |
| ||||||
| Environment: | Slackware linux 13.1, 64-bit, kernel 3.4.45 | Attachments: | ( 0) ASTERISK-23047-1.8.diff ( 1) debug.txt ( 2) debug-11.7.0.txt ( 3) extensions.conf | ||||
| Description: | Symptoms: Asterisk uses 100% CPU and has orphaned channels that don't go away.
Environment: asterisk, two SIP phones (A and B), call parking on extensions 100-106 How to reproduce (short version): Program a button of phone B as speed dial to 101. Use phone A to dial B Use asterisk attended transfer to transfer the call to the parking extension (100). You'll hear the announcement of the extensions where the call is parked. Don't hang up! Now press the speed dial button for extension 101. Both calls are now hung up. The asterisk process is using 100% CPU. There are no parked calls, but there are still two active channels. | ||||||
| Comments: | By: Roel van Meer (rolek) 2014-01-10 09:21:30.854-0600 Minimalistic extensions.conf used to reproduce the issue. By: Roel van Meer (rolek) 2014-01-10 09:32:48.011-0600 Asterisk debug log of the procedure reproducing the problem. By: Roel van Meer (rolek) 2014-01-10 09:34:00.494-0600 The orphaned channels look like this: {noformat} demo*CLI> core show channels Channel Location State Application(Data) Local/100@start-0000 s@parkedcalls:1 Up Parked Call() Local/100@start-0000 101@parkedcalls:1 Up ParkedCall(101,default) 2 active channels 1 active call 3 calls processed {noformat} or {noformat} demo*CLI> core show channels concise Local/100@start-00000000;2!parkedcalls!s!1!Up!Parked Call!!226!!!3!401!Local/100@start-00000000;1!1389367617.4 Local/100@start-00000000;1!parkedcalls!101!1!Up!ParkedCall!101,default!!!!3!401!Local/100@start-00000000;2!1389367621.5 {noformat} By: Roel van Meer (rolek) 2014-01-10 09:35:57.699-0600 If you need any more information, please let me know. This is a debug machine, I can reproduce it at will. Currently I'm using Yealink/Tiptel phones. If required, I'll try to reprocude it with other brands as well. Thanks! By: Rusty Newton (rnewton) 2014-01-10 10:25:23.482-0600 May be related to ASTERISK-23047 and ASTERISK-22834 Please test with the patch on ASTERISK-23047 and report back. Thanks! By: Roel van Meer (rolek) 2014-01-14 02:45:04.668-0600 Patch of bug 23047 reworked for Asterisk 1.8. By: Roel van Meer (rolek) 2014-01-14 02:46:49.961-0600 The patch on ASTERISK-23047 is for Asterisk 11. It needs a few small changes to apply on 1.8. I uploaded the version of the patch that I used. No change, I can still reproduce it. By: Roel van Meer (rolek) 2014-01-14 02:58:05.855-0600 I can reproduce this also with 11.7.0, both without and with the patch from ASTERISK-23047. By: Roel van Meer (rolek) 2014-01-14 02:59:28.762-0600 Is there anything else I can do? By: Matt Jordan (mjordan) 2014-01-14 09:29:57.295-0600 In ASTERISK-23047 and ASTERISK-22834, the transfer was initiated by chan_sip. In your case, you're initiating it via core DTMF features, so I'm not surprised the patch didn't resolve your issue. That being said, unfortunately, your DEBUG log isn't a properly generated DEBUG log - a DEBUG log doesn't mean just DEBUG statements, but DEBUG statements and higher - that is: {noformat} full => debug,verbose,notice,warning,error,dtmf {noformat} Instructions for generating a DEBUG log are on the Asterisk wiki: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information Please attach the new log illustrating the problem. That should help us find where in the features the off nominal path isn't being handled correctly. By: Roel van Meer (rolek) 2014-01-14 09:42:12.946-0600 Debug log of 11.7.0 according to specs. By: Roel van Meer (rolek) 2014-01-14 09:43:48.457-0600 Attached you'll find a new debug log. By: Roel van Meer (rolek) 2014-01-15 04:00:02.479-0600 By the way; the orphaned channels are not stuck; they can be hung op from the CLI with the "channel request hangup" command. Doing so brings everything back to normal. By: Rusty Newton (rnewton) 2014-01-17 08:17:30.963-0600 Thanks for the additional information Roel. When a dev is able to start work on the issue, they'll ask for any further information needed here. By: Joshua C. Colp (jcolp) 2017-12-18 11:01:06.718-0600 Is this still a problem under Asterisk 13 or above? We majorly changed how transfers and parking work. By: Roel van Meer (rolek) 2017-12-18 14:04:07.564-0600 I'll check and get back to you! By: Roel van Meer (rolek) 2017-12-19 01:19:54.529-0600 I can confirm that the problem persists with Asterisk 11.13.1 (tested with asterisk 11.13.1~dfsg-2+deb8u4 on Debian jessie). By: Joshua C. Colp (jcolp) 2017-12-19 04:19:46.858-0600 Asterisk 11 is no longer supported in any capacity[1]. I was asking if it was still applicable to Asterisk 13. [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions By: Roel van Meer (rolek) 2017-12-19 04:32:30.675-0600 Yes, I'll get back to you. I don't have a ready to use install of Asterisk 13, so it'll take me some time to set that up. By: Asterisk Team (asteriskteam) 2018-01-02 08:30:27.259-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 | ||||||