[Home]

Summary:ASTERISK-00694: masqurade whacks availability of variables set in spool file
Reporter:klasstek (klasstek)Labels:
Date Opened:2003-12-22 16:39:31.000-0600Date Closed:2011-06-07 14:10:35
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) test.call
( 1) test.log
( 2) test.py
( 3) test2.log
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.
Comments:By: klasstek (klasstek) 2003-12-22 16:41:05.000-0600

requires CVS version of pyst to use the test.py script.  Available from http://sf.net/projects/pyst

By: klasstek (klasstek) 2003-12-22 16:50:01.000-0600

Further testing shows that this is not just restricted to variables set in spool files but also those set by SetVar() in an extension prior to the Masqurade.

By: klasstek (klasstek) 2003-12-22 16:56:49.000-0600

test2.log  shows the behavior both before and after masqurade using NoOp(${JUNK}) and the like to show that the variables are also no longer available in the extension in which they were created.

By: klasstek (klasstek) 2003-12-22 16:58:28.000-0600

snippet from extensions.conf

[test]
                                                                                                                                                                             
exten = test,1,Answer
exten = test,2,SetAccount(${PFACCOUNTCODE})
exten = test,3,SetVar(JUNK=This is to see if masq whacks vars set in the extension)
exten = test,4,NoOp(VALIDATE AVAILABILITY OF VARIABLES IN THE EXTENSION)
exten = test,5,NoOp(JUNK: ${JUNK})
exten = test,6,NoOp(SPOOLJUNK: ${SPOOLJUNK})
exten = test,7,NoOp(XPHONE: ${XPHONE})
exten = test,8,AGI(test.py)
exten = test,9,NoOp(VALIDATE AVAILABILITY OF VARIABLES IN THE EXTENSION AFTER AGI/MASQ)
exten = test,10,NoOp(JUNK: ${JUNK})
exten = test,11,NoOp(SPOOLJUNK: ${SPOOLJUNK})
exten = test,12,NoOp(XPHONE: ${XPHONE})
exten = test,13,Hangup

By: Brian West (bkw918) 2004-01-17 20:34:18.000-0600

If you use chan_local from a call-file and you want to pass channel variables into your context, make sure you append the '/n', because otherwise chan_local will 'optimize' itself out of the call-path, and the variables will get lost.

By: Brian West (bkw918) 2004-01-17 20:34:42.000-0600

I didn't even know this one... oej thanks for the info.

By: Digium Subversion (svnbot) 2008-11-08 16:15:35.000-0600

Repository: asterisk
Revision: 155508

U   team/murf/masqpark/res/res_features.c

------------------------------------------------------------------------
r155508 | murf | 2008-11-08 16:15:34 -0600 (Sat, 08 Nov 2008) | 32 lines

A small change, and it gets rid of an error message about
an invalid handler not found (in some cases), when
you use one-touch parking, that you didn't see when you
initiated parking by other methods. The builtin_parkcall
routine was setting the channel exten/prio to s/1, where
none of the other paths does. Removed with a comment.

Tested using an expanded test set:

1. A calls B, A parks B, B hangs while A is getting announcement.
2.                     , B hangs up after A gets anncmnt, before parking expires
3.                     , B waits,  A is redialed, answers, and rebridged.
4.                     , B is picked up by C.
5. A calls B, B parks A, A hangs up while B is getting anncmnt.
6.                     , A hangs up after B gets anncmnt, before parking expires
7.                     , A waits, B is redialed, answers, and rebridged.
8.                     , A is picked up by C.

Where "parks" is
  I.   Feature= one-touch parking (in my case via *3)
  II.  Feature= blind xfer to parking exten (in my case ASTERISK-694)
  III. Running park app from Dialplan (dahdi hookflash, 700; or sip xfer to 700)
       (this case does not play the parking stall announcement to the parker,
        so we skip tests 1 and 5)
  IV.  Run Park via manager command interface. (I did not test this,
       as it's already doing the masq_park() thing, and I didn't change it).

So, after running all 8 tests (or 6) in the first 3 parking scenarios (I,II,III),
everything works fine.



------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=155508

By: Digium Subversion (svnbot) 2008-12-19 16:30:28.000-0600

Repository: asterisk
Revision: 166093

U   branches/1.4/apps/app_dial.c
U   branches/1.4/apps/app_queue.c
U   branches/1.4/include/asterisk/pbx.h
U   branches/1.4/res/res_features.c

------------------------------------------------------------------------
r166093 | murf | 2008-12-19 16:30:27 -0600 (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 ##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.


------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=166093

By: Digium Subversion (svnbot) 2008-12-20 14:15:36.000-0600

Repository: asterisk
Revision: 166093

U   branches/1.4/apps/app_dial.c
U   branches/1.4/apps/app_queue.c
U   branches/1.4/include/asterisk/pbx.h
U   branches/1.4/res/res_features.c

------------------------------------------------------------------------
r166093 | murf | 2008-12-19 16:30:32 -0600 (Fri, 19 Dec 2008) | 133 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 ##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=166093

By: Digium Subversion (svnbot) 2008-12-23 12:13:45.000-0600

Repository: asterisk
Revision: 166665

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

------------------------------------------------------------------------
r166665 | murf | 2008-12-23 12:13:44 -0600 (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 ##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=166665

By: Digium Subversion (svnbot) 2008-12-23 18:52:33.000-0600

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 ##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

By: Digium Subversion (svnbot) 2008-12-23 19:15:39.000-0600

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 ##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