[asterisk-bugs] [Asterisk 0013425]: One-touch parking results in stuck/deadlocked channel if parked channel hangs up while announcement still being played
Asterisk Bug Tracker
noreply at bugs.digium.com
Mon Sep 15 13:55:43 CDT 2008
A NOTE has been added to this issue.
======================================================================
http://bugs.digium.com/view.php?id=13425
======================================================================
Reported By: mdu113
Assigned To: jpeeler
======================================================================
Project: Asterisk
Issue ID: 13425
Category: Resources/res_features
Reproducibility: always
Severity: minor
Priority: normal
Status: assigned
Asterisk Version: SVN
SVN Branch (only for SVN checkouts, not tarball releases): 1.4
SVN Revision (number only!): 141028
Disclaimer on File?: N/A
Request Review:
======================================================================
Date Submitted: 2008-09-04 16:08 CDT
Last Modified: 2008-09-15 13:55 CDT
======================================================================
Summary: One-touch parking results in stuck/deadlocked
channel if parked channel hangs up while announcement still being played
Description:
This is a continuation of issue 11979. I discovered it just after I
reported everything's fine and that issue got closed. I don't see a way to
re-open it, probably because I'm not the original reporter, so I'm opening
a new issue.
The setup is exactly as I described in 11979:
- features.conf:
[featuremap]
parkcall => *30 ; Park call (one step parking)
[applicationmap]
park_caller => *33,peer/callee,AGI,park.agi|park_caller
park_callee => *33,peer/caller,AGI,park.agi|park_callee
The scenario:
2 SIP endpoints: xyz011101(polycom 501) calls xyz110001(cisco 7960), call
is connected (through FastAGI application), then I dial *30 on xyz011101 to
park the peer and hangup the peer (xyz110001) while announcement being
played to xyz011101. The result is xyz011101 is stucked. It appears in
channel list after I hang it up on the phone and sometimes (intermittently)
asterisk crashes or deadlocks after that.
Here's the console output:
-- Executing [1100 at xyz:1] Set("SIP/xyz011101-081e15f8",
"TIMEOUT(absolute)=10800") in new stack
-- Channel will hangup at 2008-09-04 23:48:14 UTC.
-- Executing [1100 at xyz:2] AGI("SIP/xyz011101-081e15f8",
"agi://devel.acecape.com") in new stack
-- AGI Script Executing Application: (SetCallerPres) Options:
(allowed_passed_screen)
-- AGI Script Executing Application: (Set) Options:
(CALLERID(name)=Unknown)
-- AGI Script Executing Application: (Set) Options:
(CALLERID(num)=Unknown)
-- AGI Script Executing Application: (Dial) Options:
(SIP/xyz110001|180|Kk)
-- Called xyz110001
-- SIP/xyz110001-081e2b88 is ringing
-- SIP/xyz110001-081e2b88 answered SIP/xyz011101-081e15f8
-- Started music on hold, class 'default', on channel
'SIP/xyz110001-081e2b88'
== Parked SIP/xyz110001-081e2b88 on 701 at parkedcalls. Will timeout back
to extension [xyz] , 1 in 600 seconds
-- <SIP/xyz011101-081e15f8> Playing 'digits/7' (language 'en')
-- Stopped music on hold on SIP/xyz110001-081e2b88
== SIP/xyz110001-081e2b88 got tired of being parked
== CDR on channel 'SIP/xyz110001-081e2b88' lacks end
== CDR on channel 'SIP/xyz110001-081e2b88' lacks end
[Sep 4 16:48:21] WARNING[24101]: res_features.c:1846 do_parking_thread:
Whoa, failed to remove the extension!
-- <SIP/xyz011101-081e15f8> Playing 'digits/0' (language 'en')
-- <SIP/xyz011101-081e15f8> Playing 'digits/1' (language 'en')
-- Added extension 'isk/var/lib/asterisk/sounds/digits/en/1.al'
priority 1 to parkedcalls
At this point I hangup xyz011101 and do "show channels":
webdevel*CLI> show channels
Channel Location State Application(Data)
SIP/xyz011101-081e15 s at xyz:1 Up
Dial(SIP/xyz110001|180|Kk)
1 active channel
1 active call
A few minutes later asterisk crashed
======================================================================
----------------------------------------------------------------------
(0092518) mdu113 (reporter) - 2008-09-15 13:55
http://bugs.digium.com/view.php?id=13425#c92518
----------------------------------------------------------------------
I've updated code to r142927 and applied your patch. Still a lot of
problems.
parking_crash1.txt - console output and backtrace of the following
scenario:
A calls B, B answers, A dials feature code to park call. In other words
one-touch parking initiated by caller leads to the crash now.
parking_crash2.txt - console output and backtrace of the following
scenario:
A calls B, B answers and diales feature code to park A. At this point
everything fine and A is parked at extension 701, i.e. one-touch parking
initiated by callee seems to work fine now. Now I wanted to test how it
would behave if parking fails, so I made my AGI application to set
PARKINGEXTEN variable to 701 for the next call and to the following: C
calls B (PARKINGEXTEN=701 is set), B answers and dials feature code to park
C. At this point asterisk crashes. gdb suggests that it crashed in
ast_cdr_start(), so it may be actually cdr problem, I don't know.
Also I wanted to say a few words about your patch. If I understand it
correctly you now chose to masquerade parked channel if feature is running
on peer. I believe there's a problem with it in current implementation.
Imagine the following situation: A calls B, B answers and attempts to park
A. Suppose the parking is failed for any reason. Again if my understanding
of the code is correct I believe the call will be dropped in this case,
because by the moment the failure is determined (in park_call_full()) the
channel already masqueraded away. I hope you'd agree with me that in case
of one-touch parking, parking failure shouldn't cause a call to be dropped
as it was the case previously.
I think you need either perform all the checks that may fail before
masquerading or somehow bridge the channel back after masquerading in case
of failure.
Issue History
Date Modified Username Field Change
======================================================================
2008-09-15 13:55 mdu113 Note Added: 0092518
======================================================================
More information about the asterisk-bugs
mailing list