[Freeswitch-users] session-api - How to continue with A-leg after bridge-timeout?

[Christian Benke]

*sigh* No answer yet :-(

Was my explanation comprehensive?

On 8 March 2012 19:31, Christian Benke <benkokakao at gmail.com> wrote:
> Hello!
>
> I have written a DB-based routing-script to be able to configure
> complex and dynamic call-behaviours but i'm currently stuck with
> scenarious where different call-channels are merged(att_xfer,
> intercept, et al), as my script fails with these scenarious.
>
> I'm testing using a simplified version of the script(nxo_test.py) to
> understand the mechanism behind those scenarious and now i'm at a
> point where i no longer know the proper tools to handle these
> situations. Here's what is happening:
>
> This is the test-script in pseudocode:
>
>> SRC=A
>> DEST=B
>> log("Test1")
>> sleep(1000)
>> log("Test2")
>> sleep(1000)
>> log("Test3")
>> bridge([origination_caller_id_number="${SRC}"]user/${DEST}@${domain_name})
>> log("Test4")
>> sleep(1000)
>> "log" "Test5"
>> sleep(1000)
>> "log" "Test6"
>
> A dials B. The call enters the default context where the test-script
> is called, the first steps are executed and the bridge is initiated.
>
> B picks up the call, the following (truncated) channel-uuids exist at
> this point:
> "a7c4"(A->)
> "a7cc"(->B)
>
> B then initiates an attended transfer to C, which follows the same
> path and script as the first call(But the call is bridged to C instead
> of B this time). Two new channels are set up - uuid's "a7d5"(B->) and
> "a7dd"(->C)
>
> B immediately transfers the call before C has picked up.
>
> Channel "a7cc"(->B) is killed by att_xfer while Channel "a7c4"(A->)
> finishes the script(The remaining Steps Test3-Test5 are executed) and
> is then automatically parked in endless_playback by att_xfer, waiting
> for C to pick up.
>
> C lets it ring until the timeout of 15s ends, "a7c4" and "a7dd" are
> hung up while a7d5 continues as a ZOMBIE-channel, trying to execute
> the remaining steps in the script(The "sleep"-commands fail due to the
> zombie-state).
>
> And this is where i'm stuck - i would like channel "a7c4" to not get
> hung up but to continue with the steps which "a7d5" could no longer
> execute. Is there some way to prevent a7c4 from getting hung up when
> the ATTENDED_TRANSFER to C fails? Algorithmically i can figure out how
> the remaining steps can get memorised and executed, i just don't know
> how to prevent "a7c4" from getting hung up and beeing transfer to a
> place where i can still work with it :-/ I can't use the HangupHook
> either, as a7c4 is already in zombie-state at that point.
>
> For reference, i've attached the test-script and a freeswitch-log of
> the call above.
>
> I hope someone can lead me on the right track...
>
> Best regards
> Christian