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

[João Mesquita]

I honest believe that you won't be able to accomplish what you want like that. I don't think you can modify the core state machine from a script and by the time you get the control back on the script, the channel is already gone because of the att_xfer inner working…

But I am really not an expert and I can barely understand how the att_xfer code works.


Regards,  

--  
João Mesquita
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)


On Friday, March 9, 2012 at 9:13 AM, Christian Benke wrote:

> *sigh* No answer yet :-(
>  
> Was my explanation comprehensive?
>  
> On 8 March 2012 19:31, Christian Benke <benkokakao at gmail.com (mailto: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
> >  
>  
>  
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org (mailto:consulting at freeswitch.org)
> http://www.freeswitchsolutions.com
>  
> 
> 
>  
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>  
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org (mailto:FreeSWITCH-users at lists.freeswitch.org)
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>  
>  


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20120309/b88e3c22/attachment.html