[asterisk-bugs] [Asterisk 0000700]: masqurade whacks availability of variables set in spool file
Asterisk Bug Tracker
noreply at bugs.digium.com
Tue Dec 23 19:15:39 CST 2008
A NOTE has been added to this issue.
======================================================================
http://bugs.digium.com/view.php?id=700
======================================================================
Reported By: klasstek
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 700
Category: Core/General
Reproducibility: always
Severity: minor
Priority: normal
Status: closed
Asterisk Version: I did not set the version :(
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Disclaimer on File?: N/A
Request Review:
Resolution: open
Fixed in Version:
======================================================================
Date Submitted: 2003-12-22 16:39 CST
Last Modified: 2008-12-23 19:15 CST
======================================================================
Summary: masqurade whacks availability of variables set in
spool file
Description:
It seems that masqurade destroys variables that are set via the spool file
or prior to the masqurade.
I'm testing this using a spool file that originates a call and connects to
an AGI script when answered. Attached are a log from two calls. One via
iaxtel and one via nufone. I do not know why one masqurades and the other
does not.
I've also attached my test script, test.call file and a log of the calls.
======================================================================
----------------------------------------------------------------------
(0096921) svnbot (reporter) - 2008-12-23 19:15
http://bugs.digium.com/view.php?id=700#c96921
----------------------------------------------------------------------
Repository: asterisk
Revision: 166730
_U branches/1.6.1/
U branches/1.6.1/apps/app_dial.c
U branches/1.6.1/apps/app_macro.c
U branches/1.6.1/apps/app_queue.c
U branches/1.6.1/include/asterisk/features.h
U branches/1.6.1/include/asterisk/pbx.h
U branches/1.6.1/main/features.c
U branches/1.6.1/main/pbx.c
------------------------------------------------------------------------
r166730 | murf | 2008-12-23 19:15:39 -0600 (Tue, 23 Dec 2008) | 165 lines
Merged revisions 166665 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
This merged from trunk with no conflicts. I tested
mostly the 'tired' cases, and for the most part
ignored the tests for reconnecting and dialing in
to fetch a parked call, after the first case.
................
r166665 | murf | 2008-12-23 11:13:49 -0700 (Tue, 23 Dec 2008) | 153
lines
Merged revisions 166093 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
In order to merge this 1.4 patch into trunk,
I had to resolve some conflicts and wait for
Russell to make some changes to res_agi.
I re-ran all the tests; 39 calls in all, and
made fairly careful notes and comparisons: I
don't want this to blow up some aspect of
asterisk; I completely removed the KEEPALIVE
from the pbx.h decls. The first 3 scenarios
involving feature park; feature xfer to 700;
hookflash park to Park() app call all behave
the same, don't appear to leave hung channels,
and no crashes.
........
r166093 | murf | 2008-12-19 15:30:32 -0700 (Fri, 19 Dec 2008) | 131
lines
This merges the masqpark branch into 1.4
These changes eliminate the need for (and use of)
the KEEPALIVE return code in res_features.c;
There are other places that use this result code
for similar purposes at a higher level, these appear
to be left alone in 1.4, but attacked in trunk.
The reason these changes are being made in 1.4, is
that parking ends a channel's life, in some situations,
and the code in the bridge (and some other places),
was not checking the result code properly, and dereferencing
the channel pointer, which could lead to memory corruption
and crashes.
Calling the masq_park function eliminates this danger
in higher levels.
A series of previous commits have replaced some parking calls
with masq_park, but this patch puts them ALL to rest,
(except one, purposely left alone because a masquerade
is done anyway), and gets rid of the code that tests
the KEEPALIVE result, and the NOHANGUP_PEER result codes.
While bug 13820 inspired this work, this patch does
not solve all the problems mentioned there.
I have tested this patch (again) to make sure I have
not introduced regressions.
Crashes that occurred when a parked party hung up
while the parking party was listening to the numbers
of the parking stall being assigned, is eliminated.
These are the cases where parking code may be activated:
1. Feature one touch (eg. *3)
2. Feature blind xfer to parking lot (eg
#http://bugs.digium.com/view.php?id=700)
3. Run Park() app from dialplan (eg sip xfer to 700)
(eg. dahdi hookflash xfer to 700)
4. Run Park via manager.
The interesting testing cases for parking are:
I. A calls B, A parks B
a. B hangs up while A is getting the numbers announced.
b. B hangs up after A gets the announcement, but
before the parking time expires
c. B waits, time expires, A is redialed,
A answers, B and A are connected, after
which, B hangs up.
d. C picks up B while still in parking lot.
II. A calls B, B parks A
a. A hangs up while B is getting the numbers announced.
b. A hangs up after B gets the announcement, but
before the parking time expires
c. A waits, time expires, B is redialed,
B answers, A and B are connected, after
which, A hangs up.
d. C picks up A while still in parking lot.
Testing this throroughly involves acting all the permutations
of I and II, in situations 1,2,3, and 4.
Since I added a few more changes (ALL references to KEEPALIVE in the
bridge
code eliimated (I missed one earlier), I retested
most of the above cases, and no crashes.
H-extension weirdness.
Current h-extension execution is not completely
correct for several of the cases.
For the case where A calls B, and A parks B, the
'h' exten is run on A's channel as soon as the park
is accomplished. This is expected behavior.
But when A calls B, and B parks A, this will be
current behavior:
After B parks A, B is hung up by the system, and
the 'h' (hangup) exten gets run, but the channel
mentioned will be a derivative of A's...
Thus, if A is DAHDI/1, and B is DAHDI/2,
the h-extension will be run on channel
Parked/DAHDI/1-1<ZOMBIE>, and the
start/answer/end info will be those
relating to Channel A.
And, in the case where A is reconnected to
B after the park time expires, when both parties
hang up after the joyful reunion, no h-exten
will be run at all.
In the case where C picks up A from the
parking lot, when either A or C hang up,
the h-exten will be run for the C channel.
CDR's are a separate issue, and not addressed
here.
As to WHY this strange behavior occurs,
the answer lies in the procedure followed
to accomplish handing over the channel
to the parking manager thread. This procedure
is called masquerading. In the process,
a duplicate copy of the channel is created,
and most of the active data is given to the
new copy. The original channel gets its name
changed to XXX<ZOMBIE> and keeps the PBX
information for the sake of the original
thread (preserving its role as a call
originator, if it had this role to begin
with), while the new channel is without
this info and becomes a call target (a
"peer").
In this case, the parking lot manager
thread is handed the new (masqueraded)
channel. It will not run an h-exten
on the channel if it hangs up while
in the parking lot. The h exten will
be run on the original channel instead,
in the original thread, after the bridge
completes.
See bug 13820 for our intentions as
to how to clean up the h exten behavior.
Review: http://reviewboard.digium.com/r/29/
........
................
------------------------------------------------------------------------
http://svn.digium.com/view/asterisk?view=rev&revision=166730
Issue History
Date Modified Username Field Change
======================================================================
2008-12-23 19:15 svnbot Checkin
2008-12-23 19:15 svnbot Note Added: 0096921
======================================================================
More information about the asterisk-bugs
mailing list