[Freeswitch-users] multiple leg and multiple rtp

[Mathieu Rene]

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 at 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 at 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 at 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 at 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 at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org