transfering caller to another context without hanging up on bridge
Hello, maybe a strange question, but is it possible to transfer the caller to another dialpla-extension, ... without hanging up an (almost) active bridge? Transferring to another context seems to hang up the bridge which was already established, but I would like to do some other actions while the bridge is active. Thank you and kind regards, Michel
what exactly are you trying to do with each leg during this time? On Mar 20, 2013, at 12:36 PM, Michel Brabants <michel.brabants@gmail.com> wrote:
Hello,
maybe a strange question, but is it possible to transfer the caller to another dialpla-extension, ... without hanging up an (almost) active bridge? Transferring to another context seems to hang up the bridge which was already established, but I would like to do some other actions while the bridge is active.
Hello, I want to implement extra actions ont he first leg. In my case send a notify-event "talk" to the second leg, but I want to make this more flexible so that the source code doesn't has to be changed each time. I changed 1 line in sofia.c that handles the notify-talk-event, so that when the option "3PCC_PROXY" has been set, freeswitch doesn't immediately answer the first leg, but that the logic can be handled in the auto_answer-context/extension. However, I noticed that just removing the answer isn't enough as the transfer in switch_ivr_transfer.c also hangs up the second leg which is in the ringing state, which is certainly not what I would like to do. So, I'm searching for a kind of background-action that I can execute on receiving the notify-talk that doesn't cancel the second leg. But I would like to keep it customisable, so I would like to handle any further actions in the dialplan, if possible, like the auto_answer-extension currently does. In other words, I would like to make the actions taken on the notfy-talk-event customisable, but in a simple way, so that persons don't have to mess with real code and that it will hopefully be accepted upstream. There are real use-cases for this (we're implementing one ...), certainly when one has set the 3PCC_PROXY-option where notifies of this kind are being used to answer the call and to also put the call on-hold (next step to investigate). Kind regards, Michel On Wed, Mar 20, 2013 at 7:23 PM, Michael Jerris <mike@jerris.com> wrote:
what exactly are you trying to do with each leg during this time?
On Mar 20, 2013, at 12:36 PM, Michel Brabants <michel.brabants@gmail.com> wrote:
Hello,
maybe a strange question, but is it possible to transfer the caller to another dialpla-extension, ... without hanging up an (almost) active bridge? Transferring to another context seems to hang up the bridge which was already established, but I would like to do some other actions while the bridge is active.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: 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 http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
participants (2)
-
Michael Jerris
-
Michel Brabants