session-api - How to continue with A-leg after bridge-timeout?
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
*sigh* No answer yet :-( Was my explanation comprehensive? On 8 March 2012 19:31, Christian Benke <benkokakao@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
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@gmail.com (mailto:benkokakao@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@freeswitch.org (mailto:consulting@freeswitch.org) http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org (mailto:FreeSWITCH-users@lists.freeswitch.org) http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
On 9 March 2012 17:05, João Mesquita <jmesquita@freeswitch.org> wrote:
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…
Hmm, what i don't understand - when i rebuild the same route-logic in XML, the initiating channel is not hung up but continues the steps in the extension it has been transfered to - which is exactly what i'm trying to achieve. See attached XML-dialplan. Can someone with a better understand of the core_state_machine please shed some light on this? Regards, Christian
Hmm, what i don't understand - when i rebuild the same route-logic in XML, the initiating channel is not hung up but continues the steps in the extension it has been transfered to
Attached is a log of this scenario, i've only added an additional "info" to the XML-dialplan posted before. The initial channel bf969cf6-6a0f-11e1-8e5c-299021af10b6 is still there at the very end of the transfered call - there must be some way to get the same result in my script-based routing and be able to reroute this initial channel? Regards, Christian
I am sorry Christian, I would need to defer this to someone with more knowledge on the matter. -- João Mesquita Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Friday, March 9, 2012 at 2:51 PM, Christian Benke wrote:
Hmm, what i don't understand - when i rebuild the same route-logic in XML, the initiating channel is not hung up but continues the steps in the extension it has been transfered to
Attached is a log of this scenario, i've only added an additional "info" to the XML-dialplan posted before.
The initial channel bf969cf6-6a0f-11e1-8e5c-299021af10b6 is still there at the very end of the transfered call - there must be some way to get the same result in my script-based routing and be able to reroute this initial channel?
Regards, Christian
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org (mailto:consulting@freeswitch.org) http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org (mailto:FreeSWITCH-users@lists.freeswitch.org) http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Attachments: - freeswitch_XML_DP_log.txt
On 09/03/12 17:51, Christian Benke wrote:
Hmm, what i don't understand - when i rebuild the same route-logic in XML, the initiating channel is not hung up but continues the steps in the extension it has been transfered to Attached is a log of this scenario, i've only added an additional "info" to the XML-dialplan posted before.
The initial channel bf969cf6-6a0f-11e1-8e5c-299021af10b6 is still there at the very end of the transfered call - there must be some way to get the same result in my script-based routing and be able to reroute this initial channel?
Christian, It sounds like something that would be better driven from the ESL rather than a script that effectively forms part of the dialplan. As João says, when you lose the leg you are executing inside, you lose control. Also, you are far better posting logs to pastebin.freeswitch.org. The URL stays in the original post whereas the attachment gets lost further down the post chain. And they are easier to read. John
On 9 March 2012 21:55, John <freeswitch@earthspike.net> wrote:
It sounds like something that would be better driven from the ESL rather than a script that effectively forms part of the dialplan. As João says, when you lose the leg you are executing inside, you lose control.
Hmm, I think i found the cause of the problem - Polycom is handling "Attended Transfers" resp. "Consultation Transfers" somewhat unorthodox, where B does not have to wait for C to pickup - FS can't cope well with this situation. A proper Attended Transfer or a proper Blind Transfer handles these situations much better. Anthony pointed this out to me offlist on an other issue. In essence, i have the option to reconfigure my Polycoms to not allow to transfer unanswered Attended Transfers with the parameter "voIpProt.SIP.allowTransferOnProceeding" - and instruct my clients how to use a "real" Blind Transfer instead. With a proper Blind Transfer, A sends a invite to C and the call is reinitated properly from the start. This issue was really bugging me for 2 weeks now, but the solution appears simple and at a totally different place than i had looked. Who would have thought? :-) Sometimes you lose sight of the forest for the trees...
Also, you are far better posting logs to pastebin.freeswitch.org. The URL stays in the original post whereas the attachment gets lost further down the post chain. And they are easier to read.
Ah, yeah, thanks. I was so distracted and cocerned that i forgot about that ;-) Cheers, Christian
participants (3)
-
Christian Benke
-
John
-
João Mesquita