ok both methods work now. your jira was fixed in r16311 and the non bypass equivalent was fixed in the previous commit On Thu, Jan 14, 2010 at 11:00 AM, Sergey Okhapkin <sos@sokhapkin.dyndns.org>wrote:
"hangup_after_bridge=false" is the default setting.
On Thursday 14 January 2010, Mathieu Rene wrote:
One way you could fix it is set "hangup_after_bridge=false" and then set "execute_on_answer=set\shangup_after_bridge=true". That will make it continue executing the dialplan atter a failure that came in after 183. Note that there is a side effect to this method, since audio was being relayed, you are forced to use the same codec on the 2nd carrier, best to tell them they are wrong failing a call after 183.
Mathieu Rene Avant-Garde Solutions Inc Office: + 1 (514) 664-1044 x100 Cell: +1 (514) 664-1044 x200 mrene@avgs.ca
On 14-Jan-10, at 11:41 AM, Sergey Okhapkin wrote:
Anthony, I apology, I didn't expect you'll be annoyed. As for the issue, the issue is not in "proxy_media" setting, same happens when both "proxy_media" and "bypass_media" are not set. The code does explicit leg A hangup in switch_ivr_bridge.c, line 513. The condition there is "if leg A is up and leg A is not in answered state, then hangup leg A", this prevents dialplan to continue execution on early media bridge termination.
Issue when "bypass_media=true" is completely different, I'll open the issue on jira.
On Thursday 14 January 2010, Anthony Minessale wrote:
Sergey,
The bug you reference was closed because proxy_media mode by design send's the B leg's codec to the A LEG so if there is a failure condition there is no easy graceful way to back out and try another call. I will try to make it possible if yo post a bounty, I estimate a minimum of $1000USD in consulting time.
The other one I might look at once you have apologized.
I can probably add some code to make the bridge exit without terminating the A leg even when hangup_after_bridge=true in the case where the the B leg is not answered but right now I am sort of annoyed with your attitude in this thread.
On Thu, Jan 14, 2010 at 6:19 AM, Sergey Okhapkin
<sos@sokhapkin.dyndns.org>wrote:
Case 1 (bypass_media is off) is already on jira, http://jira.freeswitch.org/browse/FSCORE-257 , I will prepare a test installation with latest trunk to reproduce case 2, when bypass_media=true and 10 seconds delay happens when 18X and then error are received on leg b.
On Wednesday 13 January 2010, Michael Jerris wrote:
On Jan 13, 2010, at 11:08 PM, Sergey Okhapkin wrote: > Critical issues are when SIP error come after 18X provisional > response. > > - if bypass_media is false then dialplan stops and leg a is > explicitly hang up (switch_ivr_bridge.c, line 513).
behavior can be modified with continue_on_fail and hangup_after_bridge channel vars, perhaps ignore_early_media as well
> - if bypass_media is true, then dialplan continue, but there is 10 > seconds delay before next bridge application sends INVITE to > gateway > (
http://lists.freeswitch.org/pipermail/freeswitch-users/2010-January/024
35
> 4.html ) I didn't track down yet why this happens looking at FS > sources.
see response on that thread
> Why I didn't open a bug on jira? Because FS behaves according to > the > design and specs :-) But not according to real world > requirements...
Really, people are trying to help you and your going to be snarky in response?
> On Wednesday 13 January 2010, Brian West wrote: >> Can you elaborate on these "Critical" issues you seem to be >> having?
Why
>> aren't you opening a jira for them if they are that critical to >> your >> needs?
Mike
_______________________________________________ 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-use r s http://www.freeswitch.org
_______________________________________________ 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-user s http://www.freeswitch.org
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ 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
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900