[Home]

Summary:ASTERISK-23047: Orphaned (stuck) channel occurs during a failed SIP transfer to parking space
Reporter:Tommy Thompson (tthompson)Labels:
Date Opened:2013-12-20 10:18:41.000-0600Date Closed:2014-01-14 09:34:55.000-0600
Priority:CriticalRegression?
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:11.6.0 Frequency of
Occurrence		Frequent
Related
Issues:
is related toASTERISK-22834 Parking by blind transfer when lot full orphans channels
is related toASTERISK-23130 Transfer of parked call causes 100% CPU and orphaned channels
Environment:Asterisk 11.6.0-rc1 built by digium @ testpbx227-1 on a i686 running Linux on 2013-09-20 15:41:36 UTC Attachments:( 0) ASTERISK-23047-11.diff
( 1) testlog.0
Description:While running automated phone test (BLF status) asterisk has orphaned a channel. This was reproduced a second time running the same test between the same to device (digium phones) and a verbose debug log is attached.

Below is the result of sip show channels with the phones on-hook while in this state ...
{noformat}
testpbx227-1*CLI> sip show channels
Peer             User/ANR         Call ID          Format           Hold     Last Message    Expiry     Peer      
10.24.19.187     1614             Mb-Oiy1ExoNQb4V  (ulaw)           No       Rx: BYE                    1614      
10.24.16.115     1601             1990fc177becb3f  (ulaw)           No       Rx: BYE         Done       1601      
2 active SIP dialogs
{noformat}
Below is the result of "core show channels" in same state as above...
{noformat}
testpbx227-1*CLI> core show channels
Channel              Location             State   Application(Data)            
SIP/1614-00000006    1601@sip:11          Up      (None)                        
SIP/1601-00000007    (None)               Up      (None)                        
2 active channels
0 active calls
{noformat}
Comments:By: Matt Jordan (mjordan) 2014-01-02 15:25:41.721-0600

I was able to reproduce this by forcing a failed SIP transfer to the parking space. Looking at the logs, that appears to be what's happening here.

In {{sip_park_thread}}, we don't hang up the {{transferer}}/{{transferee}} channels if a call park fails. In fact, there's even a comment that says "Don't hang up the channels". It's possible that back in [r21157|https://code.asterisk.org/code/changelog/asterisk?cs=21157] the features code would have handled this differently: now, the channels are stuck in limbo with no thread to service them. As such, any subsequent hangups are ignored.

The attached patch should fix the problem by hanging up both channels in the case of a failure.
By: rsw686 (rsw686) 2014-01-02 19:32:44.513-0600

This sounds similar to issue ASTERISK-22834 I reported. I tested the attached patch and it resolved my issue. Transferring to a full parking lot no longer results in two orphaned channels.
By: Tommy Thompson (tthompson) 2014-01-10 10:31:11.898-0600

Compiled asterisk with patch and ran automated test multiple times with no failures...