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