Merged revisions 166093 via svnmerge from
authorSteve Murphy <murf@digium.com>
Tue, 23 Dec 2008 18:13:49 +0000 (18:13 +0000)
committerSteve Murphy <murf@digium.com>
Tue, 23 Dec 2008 18:13:49 +0000 (18:13 +0000)
commitaa905e347e971689f036ed9a2bf5238c67af31c6
tree6159719c831f97f21c41faa46ccc8b9ebcf710fc
parenta6e7267f451b6786a9ea6daf759ad0aff4d74392
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/

........

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@166665 65c4cc65-6c06-0410-ace0-fbb531ad65f3
apps/app_dial.c
apps/app_macro.c
apps/app_queue.c
include/asterisk/features.h
include/asterisk/pbx.h
main/features.c
main/pbx.c