If that's the case then you also need ignore_early_media=true: <action application="bridge" data="{ignore_early_media=true}sofia/internal/1001@$${domain}"/> If you don't ignore early media then the bridge app assumes that when it receives media from the far end that the bridge is "successful" even if you don't actually get a 200OK. The caveat is that since you're ignoring early media (i.e. ringing) from the B leg that you will need to supply some sort of ringing indicator to the A leg. The good news is that you can do whatever you want; just use the ring_back chan var. -MC On Thu, Aug 30, 2012 at 12:07 AM, Alex Massover <alex@jajah.com> wrote:
Hi Michael,****
** **
Thanks, that works in scenario when B legs response with 100 and then let's say 486. But if B legs do ringing, i.e. 100, 180/183, 486 it doesn't work.****
** **
I found this in wiki "By the way, you'll be unable to rewrite the hangup cause for a bridge that gets a 180 or 183 packet from the gateway before getting a 4xx, 5xx or 6xx packet (because those bridges don't 'fail')."*** *
** **
I understand that continue_on_fail won't help with this scenario. I see that's a popular topic in the list, but nobody got a solution.****
** **
BR, Alex.****
** **
*From:* freeswitch-users-bounces@lists.freeswitch.org [mailto: freeswitch-users-bounces@lists.freeswitch.org] *On Behalf Of *Michael Collins *Sent:* Wednesday, August 29, 2012 6:21 PM *To:* FreeSWITCH Users Help *Subject:* Re: [Freeswitch-users] Prevent A leg from hangup after bridge with inbound ESL socket****
** **
Try this: http://wiki.freeswitch.org/wiki/Channel_Variables#continue_on_fail
-MC****
On Wed, Aug 29, 2012 at 6:57 AM, Alex Massover <alex@jajah.com> wrote:****
Hi,****
****
I have a very simple dialplan that just do park for incoming calls. All rest of leg management is done via ESL inbound socket.****
****
I'm trying to do the same behavior like in this dialplan example, but from ESL inbound socket:****
<action application="set" data="hangup_after_bridge=false"/> ****
<action application="bridge" data="sofia/internal/1001@$${domain}"/>*** *
<action application="bridge" data="sofia/internal/1002@$${domain}"/>*** *
****
The problem is with bridge API, if B leg doesn't answer (e.g. 404, or busy), A leg disconnects. But I'm trying to prevent A leg from disconnecting in order to do bridge to other place.****
****
Looks like hangup_after_bridge=false, park_after_bridge=true, transfer_after_bridge etc don't have any effect when bridge done from inbound socket. A leg disconnects always.****
****
Is there any way to keep A leg after bridge with inbound socket? I'm aware of originate, but prefer to user bridge.****
****
****
****
****
--****
Best Regards,****
Alex Massover****
****
_________________________________________________________________________ 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****
-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.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
-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org