<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:rgb(51,51,153)">Hi All,</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:rgb(51,51,153)">
<br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:rgb(51,51,153)">Using version 1.2.9</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:rgb(51,51,153)">
<br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:rgb(51,51,153)">Just wondering if this ever got resolved as i am having a similar issue. </div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:rgb(51,51,153)">
<br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:rgb(51,51,153)">I am also using ESL inbound and my event driven script will answer the call, set the ringback to a UK tone, play 1 second of silence, then issue the bridge as follows:</div>
<div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:rgb(51,51,153)"><br></div><div class="gmail_default"><font color="#333399" face="verdana, sans-serif">{ignore_early_media=true,continue_on_fail=true,park_after_bridge=true,hangup_after_bridge=false}sofia/external/<a href="mailto:200010006@sipserv.net">200010006@sipserv.net</a></font><br>
</div><div class="gmail_default"><font color="#333399" face="verdana, sans-serif"><br></font></div><div class="gmail_default"><font color="#333399" face="verdana, sans-serif">Once this has all gone through everything works correctly when the user is available. When busy however the calling channel is ending the call rather than returning to park. I had anticipated collecting the CHANNEL_EXECUTE_COMPLETE event for the bridge command, reading the variable_DIALSTATUS for "BUSY" and then playing busy tone but it is just hanging up.</font></div>
<div class="gmail_default"><font color="#333399" face="verdana, sans-serif"><br></font></div><div class="gmail_default"><font color="#333399" face="verdana, sans-serif">Is there a clean way to resolve this? Even if its just setting the "busytone" equivalent of "ringback" that would probably do?</font></div>
<div class="gmail_default"><font color="#333399" face="verdana, sans-serif"><br></font></div><div class="gmail_default"><font color="#333399" face="verdana, sans-serif">Any help would be appreciated,</font></div><div class="gmail_default">
<font color="#333399" face="verdana, sans-serif"><br></font></div><div class="gmail_default"><font color="#333399" face="verdana, sans-serif">Thanks,</font></div><div class="gmail_default"><font color="#333399" face="verdana, sans-serif"><br>
</font></div><div class="gmail_default"><font color="#333399" face="verdana, sans-serif">Callum</font></div></div><div class="gmail_extra"><br clear="all"><div><pre style="word-wrap:break-word;white-space:pre-wrap"><font face="verdana, sans-serif" color="#333399">______________________________</font><font size="1" face="verdana, sans-serif" color="#333399">
Callum Guy
Developer
X-on
Framlingham Technology Centre
Station Road, Framlingham,
Suffolk, IP13 9EZ
T 0333 332 0116
E <a href="mailto:callum.guy@x-on.co.uk" target="_blank">callum.guy@x-on.co.uk</a>
<img src="http://www.x-ondata.com/images/footerv2.jpg">
<br></font></pre><pre style="word-wrap:break-word;white-space:pre-wrap"><font size="1" face="verdana, sans-serif" color="#333399">X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales
Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD
Company Registration No. 2578478
This email has been sent from X-on.The contents and attachments are confidential to the sender and the intended addressees.If the message
is received by anyone other than the addressee please return the message to the sender by replying to it and then delete the message from
your computer without copying or disclosing the contents to anyone.Opinions, conclusions and statements of intent in this email are those of
the sender and do not bind X-on unless confirmed by authorised representatives independently of this message.While best endeavours have
been taken to avoid transmission of viruses, it is the responsibility of the recipient to scan for these.Please note emails sent to and from X-on
are routinely monitored for record keeping and quality control, to ensure regulatory compliance and prevent unauthorised use of our systems.
</font><font size="1" face="verdana, sans-serif" color="#006600">Please consider the environment before printing this email.</font></pre></div>
<br><br><div class="gmail_quote">On 3 September 2012 10:28, Peter Olsson <span dir="ltr"><<a href="mailto:peter.olsson@visionutveckling.se" target="_blank">peter.olsson@visionutveckling.se</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
try park_after_bridge=true, it should park the call again after the bridge, and keep it alive.<br>
<br>
/Peter<br>
________________________________<br>
Från: <a href="mailto:freeswitch-users-bounces@lists.freeswitch.org">freeswitch-users-bounces@lists.freeswitch.org</a> [<a href="mailto:freeswitch-users-bounces@lists.freeswitch.org">freeswitch-users-bounces@lists.freeswitch.org</a>] för Alex Massover [<a href="mailto:alex@jajah.com">alex@jajah.com</a>]<br>
Skickat: den 3 september 2012 09:00<br>
Till: FreeSWITCH Users Help<br>
Ämne: Re: [Freeswitch-users] Prevent A leg from hangup after bridge with inbound ESL socket<br>
<div class="im"><br>
Hi,<br>
<br>
We tried that, it doesn't do a trick, the bridge app still assumes success, even if 180 is not forwarded to A leg.<br>
But I think the problem is related to ESL socket, especially to inbound socket. I'm pretty sure that all these things work with dailplan, and as far as I remember even with outbound socket it's much easier. But looks like outbound socket bypass some of these flags, as channel is control by XML dialplan, but then is bridged by ESL API and not sure what exactly happens. I understand that hangup_after_bridge=false may not work, as it's not clear what should happen with the channel in case of inbound socket (as dialplan is ended), but no reason for park_after_bridge=true not to park a channel.<br>
<br>
Maybe it worth to fill a bug in JIRA about park_after_bridge=true and ESL inbound socket. I'll do some more clear tests and will fill one.<br>
<br>
BR, Alex.<br>
<br>
<br>
From: <a href="mailto:freeswitch-users-bounces@lists.freeswitch.org">freeswitch-users-bounces@lists.freeswitch.org</a> [mailto:<a href="mailto:freeswitch-users-bounces@lists.freeswitch.org">freeswitch-users-bounces@lists.freeswitch.org</a>] On Behalf Of Michael Collins<br>
Sent: Thursday, August 30, 2012 7:17 PM<br>
To: FreeSWITCH Users Help<br>
Subject: Re: [Freeswitch-users] Prevent A leg from hangup after bridge with inbound ESL socket<br>
<br>
If that's the case then you also need ignore_early_media=true:<br>
<action application="bridge" data="{ignore_early_media=true}sofia/internal/1001@$${domain}"/><br>
<br>
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.<br>
<br>
-MC<br>
</div><div class="im">On Thu, Aug 30, 2012 at 12:07 AM, Alex Massover <<a href="mailto:alex@jajah.com">alex@jajah.com</a><mailto:<a href="mailto:alex@jajah.com">alex@jajah.com</a>>> wrote:<br>
Hi Michael,<br>
<br>
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.<br>
<br>
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')."<br>
<br>
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>
<br>
BR, Alex.<br>
<br>
</div>From: <a href="mailto:freeswitch-users-bounces@lists.freeswitch.org">freeswitch-users-bounces@lists.freeswitch.org</a><mailto:<a href="mailto:freeswitch-users-bounces@lists.freeswitch.org">freeswitch-users-bounces@lists.freeswitch.org</a>> [mailto:<a href="mailto:freeswitch-users-bounces@lists.freeswitch.org">freeswitch-users-bounces@lists.freeswitch.org</a><mailto:<a href="mailto:freeswitch-users-bounces@lists.freeswitch.org">freeswitch-users-bounces@lists.freeswitch.org</a>>] On Behalf Of Michael Collins<br>
<div class="im">Sent: Wednesday, August 29, 2012 6:21 PM<br>
To: FreeSWITCH Users Help<br>
Subject: Re: [Freeswitch-users] Prevent A leg from hangup after bridge with inbound ESL socket<br>
<br>
Try this:<br>
<a href="http://wiki.freeswitch.org/wiki/Channel_Variables#continue_on_fail" target="_blank">http://wiki.freeswitch.org/wiki/Channel_Variables#continue_on_fail</a><br>
<br>
-MC<br>
</div><div class="im">On Wed, Aug 29, 2012 at 6:57 AM, Alex Massover <<a href="mailto:alex@jajah.com">alex@jajah.com</a><mailto:<a href="mailto:alex@jajah.com">alex@jajah.com</a>>> wrote:<br>
Hi,<br>
<br>
I have a very simple dialplan that just do park for incoming calls. All rest of leg management is done via ESL inbound socket.<br>
<br>
I'm trying to do the same behavior like in this dialplan example, but from ESL inbound socket:<br>
<action application="set" data="hangup_after_bridge=false"/><br>
<action application="bridge" data="sofia/internal/1001@$${domain}"/><br>
<action application="bridge" data="sofia/internal/1002@$${domain}"/><br>
<br>
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.<br>
<br>
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.<br>
<br>
Is there any way to keep A leg after bridge with inbound socket? I'm aware of originate, but prefer to user bridge.<br>
<br>
<br>
<br>
<br>
--<br>
Best Regards,<br>
Alex Massover<br>
<br>
<br>
_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
</div><a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><mailto:<a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a>><br>
<div class="im"><a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
<a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
<a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
<br>
FreeSWITCH-users mailing list<br>
</div><a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><mailto:<a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a>><br>
<div class="im"><a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br>
<br>
<br>
--<br>
Michael S Collins<br>
Twitter: @mercutioviz<br>
<a href="http://www.FreeSWITCH.org" target="_blank">http://www.FreeSWITCH.org</a><br>
<a href="http://www.ClueCon.com" target="_blank">http://www.ClueCon.com</a><br>
<a href="http://www.OSTAG.org" target="_blank">http://www.OSTAG.org</a><br>
<br>
_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
</div><a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><mailto:<a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a>><br>
<div class="im"><a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
<a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
<a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
<br>
FreeSWITCH-users mailing list<br>
</div><a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><mailto:<a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a>><br>
<div class="im"><a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br>
<br>
<br>
--<br>
Michael S Collins<br>
Twitter: @mercutioviz<br>
<a href="http://www.FreeSWITCH.org" target="_blank">http://www.FreeSWITCH.org</a><br>
<a href="http://www.ClueCon.com" target="_blank">http://www.ClueCon.com</a><br>
<a href="http://www.OSTAG.org" target="_blank">http://www.OSTAG.org</a><br>
<br>
</div>!DSPAM:504453d832762136219851!<br>
<div class="HOEnZb"><div class="h5"><br>
_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
<a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
<a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
</div></div></blockquote></div><br></div>