[asterisk-commits] r166093 - svn:log

Sat Dec 20 14:15:40 CST 2008

Author: murf
Revision: 166093
Modified property: svn:log

Modified: svn:log at Sat Dec 20 14:15:40 2008
------------------------------------------------------------------------------

--- svn:log (original)
+++ svn:log Sat Dec 20 14:15:40 2008
@@ -1,0 +1,132 @@
+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/
+


