Asterisk
  1. Asterisk
  2. ASTERISK-694

masqurade whacks availability of variables set in spool file

    Details

    • Type: Bug Bug
    • Status: Closed
    • Severity: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Target Release Version/s: None
    • Component/s: Core/General
    • Labels:
      None
    • Mantis ID:
      700
    • Regression:
      No

      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.

      1. 0000700-test.call
        0.3 kB
      2. 0000700-test.log
        18 kB
      3. 0000700-test.py
        0.6 kB
      4. 0000700-test2.log
        8 kB
      No reviews matched the request. Check your Options in the drop-down menu of this sections header.

        Activity

        Hide
        Digium Subversion added a comment -

        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

        Show
        Digium Subversion added a comment - 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
        Hide
        Digium Subversion added a comment -

        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

        Show
        Digium Subversion added a comment - 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
        Hide
        Digium Subversion added a comment -

        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

        Show
        Digium Subversion added a comment - 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
        Hide
        Digium Subversion added a comment -

        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

        Show
        Digium Subversion added a comment - 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
        Hide
        Digium Subversion added a comment -

        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

        Show
        Digium Subversion added a comment - 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

          People

          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development