I have a query relating to the "park_after_bridge" channel variable: Firstly, I find the definition in the wiki a little vague - could do with an example (which I will provide once I'm sure I understand what it's supposed to do) If on an a-leg, I initiate a b-leg by executing bridge with park_after_bridge=true, the idea is that the a-leg could terminate and the b-leg stays connected. How about if I initiate a b-leg without park_after_bridge, but then while the calls are connected, set park_after_bridge=true (a b-leg channel variable) then when a-leg terminates, will b-leg still be parked?
I have tried this scenario and it did not work for me setting park_after_bridge while in a bridge. It seems to accept only the value that was set before the bridge. That's only my personal experience as I was trying to fix some issues with this as well. Regards, Ali Pey On Tue, Feb 18, 2014 at 12:19 PM, Alex Lake <alex@digitalmail.com> wrote:
I have a query relating to the "park_after_bridge" channel variable:
Firstly, I find the definition in the wiki a little vague - could do with an example (which I will provide once I'm sure I understand what it's supposed to do)
If on an a-leg, I initiate a b-leg by executing bridge with park_after_bridge=true, the idea is that the a-leg could terminate and the b-leg stays connected.
How about if I initiate a b-leg without park_after_bridge, but then while the calls are connected, set park_after_bridge=true (a b-leg channel variable) then when a-leg terminates, will b-leg still be parked?
_________________________________________________________________________ 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
I set it while on a bridge, and it works just fine. In my call control abstraction library, when moving multiple calls to a bridge or joining two bridges it sets it, does a bunch of transfers, and then clears it. Works great! --Dave _____ From: Ali Pey [mailto:alipey@gmail.com] To: FreeSWITCH Users Help [mailto:freeswitch-users@lists.freeswitch.org] Sent: Tue, 18 Feb 2014 12:04:37 -0800 Subject: Re: [Freeswitch-users] park_after_bridge I have tried this scenario and it did not work for me setting park_after_bridge while in a bridge. It seems to accept only the value that was set before the bridge. That's only my personal experience as I was trying to fix some issues with this as well. Regards, Ali Pey On Tue, Feb 18, 2014 at 12:19 PM, Alex Lake <alex@digitalmail.com> wrote: I have a query relating to the "park_after_bridge" channel variable: Firstly, I find the definition in the wiki a little vague - could do with an example (which I will provide once I'm sure I understand what it's supposed to do) If on an a-leg, I initiate a b-leg by executing bridge with park_after_bridge=true, the idea is that the a-leg could terminate and the b-leg stays connected. How about if I initiate a b-leg without park_after_bridge, but then while the calls are connected, set park_after_bridge=true (a b-leg channel variable) then when a-leg terminates, will b-leg still be parked? _________________________________________________________________________ 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
Just looking at the documentation: "hangup_after_bridge" Controls what happens to a calling (A) party when in a bridge state and the called (B) party hangs up. If "true" the dialplan will stop processing and the A leg will be terminated when the B leg terminates. If "false" (default) the dialplan continues to be processed after the B leg terminates. This is checked afterpark_after_bridge <http://wiki.freeswitch.org/wiki/Variable_park_after_bridge>andtransfer_after_bridge <http://wiki.freeswitch.org/wiki/Variable_transfer_after_bridge>. - this is pretty clear. "park_after_bridge" If set to true, it willpark <http://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_park>the call afterbridge <http://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_bridge>returns. This is checked beforetransfer_after_bridge <http://wiki.freeswitch.org/wiki/Variable_transfer_after_bridge>andhangup_after_bridge <http://wiki.freeswitch.org/wiki/Variable_hangup_after_bridge>. - This is not nearly so clear! Which of these things (if either!) control what happens to the called (B) party when the calling (A) party with which it is bridged hangs up?
I believe it's hangup_after_bridge, but it would be awesome if you could test it and report back here and update the wiki. Regards, Ali Pey On Thu, Feb 27, 2014 at 10:53 AM, Alex Lake <alex@digitalmail.com> wrote:
Just looking at the documentation:
"hangup_after_bridge"
Controls what happens to a calling (A) party when in a bridge state and the called (B) party hangs up. If "true" the dialplan will stop processing and the A leg will be terminated when the B leg terminates. If "false" (default) the dialplan continues to be processed after the B leg terminates. This is checked after park_after_bridge<http://wiki.freeswitch.org/wiki/Variable_park_after_bridge> and transfer_after_bridge<http://wiki.freeswitch.org/wiki/Variable_transfer_after_bridge> .
- this is pretty clear.
"park_after_bridge"
If set to true, it will park<http://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_park> the call after bridge<http://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_bridge> returns. This is checked before transfer_after_bridge<http://wiki.freeswitch.org/wiki/Variable_transfer_after_bridge> and hangup_after_bridge<http://wiki.freeswitch.org/wiki/Variable_hangup_after_bridge> .
- This is not nearly so clear!
Which of these things (if either!) control what happens to the called (B) party when the calling (A) party with which it is bridged hangs up?
_________________________________________________________________________ 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
Mmmm. Maybe a good idea!
I believe it's hangup_after_bridge, but it would be awesome if you could test it and report back here and update the wiki.
Regards, Ali Pey
On Thu, Feb 27, 2014 at 10:53 AM, Alex Lake <alex@digitalmail.com <mailto:alex@digitalmail.com>> wrote:
Just looking at the documentation:
"hangup_after_bridge"
Controls what happens to a calling (A) party when in a bridge state and the called (B) party hangs up. If "true" the dialplan will stop processing and the A leg will be terminated when the B leg terminates. If "false" (default) the dialplan continues to be processed after the B leg terminates. This is checked afterpark_after_bridge <http://wiki.freeswitch.org/wiki/Variable_park_after_bridge>andtransfer_after_bridge <http://wiki.freeswitch.org/wiki/Variable_transfer_after_bridge>.
- this is pretty clear.
"park_after_bridge"
If set to true, it willpark <http://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_park>the call afterbridge <http://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_bridge>returns. This is checked beforetransfer_after_bridge <http://wiki.freeswitch.org/wiki/Variable_transfer_after_bridge>andhangup_after_bridge <http://wiki.freeswitch.org/wiki/Variable_hangup_after_bridge>.
- This is not nearly so clear!
Which of these things (if either!) control what happens to the called (B) party when the calling (A) party with which it is bridged hangs up?
_________________________________________________________________________ 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
_________________________________________________________________________ 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
No virus found in this message. Checked by AVG - www.avg.com <http://www.avg.com> Version: 2014.0.4259 / Virus Database: 3705/7129 - Release Date: 02/27/14
participants (3)
-
Alex Lake
-
Ali Pey
-
Dave R. Kompel