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/02435
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-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