|Summary:||ASTERISK-10768: Parking into already taken parking slot leaves stalls channels and partially blocks asterisk (fix to issue 11237 is bad)|
|Date Opened:||2007-11-14 17:59:00.000-0600||Date Closed:||2007-12-28 14:37:26.000-0600|
|Description:||This is related to issue 9723 and 11237. |
The fix for issue 11237 (svn commit 89248 that just reverted changes made for issue 9723) isn't good enough as it brought back all the problems described in issue 9723.
After a failed parking attempt I now again see stucked channels and 'restart now' doesn't work. I didn't notice CLI blocks at this time, but may be I didn't try hard enough. The debug info reported in issue 9723 is all applicable again.
****** ADDITIONAL INFORMATION ******
I didn't find a way to re-open issue 11237, probably because it wasn't opened by me, so I opened another issue. Sorry if it wasn't the right thing to do.
|Comments:||By: Jason Parker (jparker) 2007-11-15 13:55:58.000-0600|
As stated in the commit message, you will need to handle this "failure" in your dialplan. You can repark using a different slot, or simply hangup.
By: mdu113 (mdu113) 2007-11-15 15:46:56.000-0600
I'd be happy to handle that in dialplan. The issue is that asterisk doesn't behave. The detailed description and debug info exists in issue 9723.
Now it's all the same. If I'm attempting to transfer a SIP channel into a parking lot that's already taken the channel is stuck and after all calls hung up are still appearing in 'show channes':
devel*CLI> show channels verbose
Channel Context Extension Prio State Application Data CallerID Duration Accountcode BridgedTo
SIP/1212812120701000 xyz s 1 Up (None) (None) 100 00:15:16 (None)
SIP/xyz011102-08208a xyz 100 3 Up (None) (None) 111 (None)
2 active channels
0 active calls
Please note there's no active calls/channels in system now. These are leftovers of failed parking attempt. SIP/xyz011102 called SIP/1212812120701000, then SIP/1212812120701000 attempted to park it into parking lot that was already busy. Then both channels hung up.
Also I specifically put additional logging into dialplan to check if asterisk continues execution at the next priority.
Here's the dialplan:
exten => *33,1,Set(PARKINGEXTEN=1001)
exten => *33,n,Park
exten => *33,n,NoOp(parking lot busy)
exten => *33,n,HangUp
Asterisk doesn't execute NoOp application even if lot 1001 is busy.
If you want I can recollect all debugging info, but again it all exists in issue 9723 and as I far as I see it's all valid again.
By: Jon Webster (jon) 2007-12-07 00:40:24.000-0600
I just discovered the same thing, that even with this change, the next priority still isn't executed. After re-opening 11237 I stumbled upon this report. Although I haven't seen any of the weird things mentioned in 9723 Park() is definitely not working as intended.
By: Tilghman Lesher (tilghman) 2007-12-28 09:32:37.000-0600
I'm closing this report, as ASTERISK-10756 has been reopened.
By: Jason Parker (jparker) 2007-12-28 14:37:26.000-0600
A patch has been uploaded to ASTERISK-10756 - give it a try, and report results there.