[Home]

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-0600Date Closed:2018-01-02 08:30:27.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Transfers Resources/General Resources/res_parking
Versions:1.8.25.0 11.7.0 Frequency of
Occurrence
Constant
Related
Issues:
is related toASTERISK-23047 Orphaned (stuck) channel occurs during a failed SIP transfer to parking space
is related toASTERISK-22834 Parking by blind transfer when lot full orphans channels
Environment:Slackware linux 13.1, 64-bit, kernel 3.4.45Attachments:( 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