[asterisk-bugs] [Asterisk 0000700]: masqurade whacks availability of variables set in spool file

Asterisk Bug Tracker noreply at bugs.digium.com
Tue Dec 23 18:52:33 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 18:52 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.
====================================================================== 

---------------------------------------------------------------------- 
 (0096920) svnbot (reporter) - 2008-12-23 18:52
 http://bugs.digium.com/view.php?id=700#c96920 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 166729

_U  branches/1.6.0/
U   branches/1.6.0/apps/app_dial.c
U   branches/1.6.0/apps/app_macro.c
U   branches/1.6.0/apps/app_queue.c
U   branches/1.6.0/include/asterisk/features.h
U   branches/1.6.0/include/asterisk/pbx.h
U   branches/1.6.0/main/features.c
U   branches/1.6.0/main/pbx.c

------------------------------------------------------------------------
r166729 | murf | 2008-12-23 18:52:32 -0600 (Tue, 23 Dec 2008) | 166 lines

Merged revisions 166665 via svnmerge from 
https://origsvn.digium.com/svn/asterisk/trunk

Due to non-symmetrical updating, I had some fairly
interesting conflicts to straighten out in this
release. The changes were such that I was compelled
to run thru all the same tests as trunk, which turned
up some problems, which I fixed. 

................
  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=166729 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-12-23 18:52 svnbot         Checkin                                      
2008-12-23 18:52 svnbot         Note Added: 0096920                          
======================================================================




More information about the asterisk-bugs mailing list