Anthony,
 
     Thanks. I understand it's complicated. Another option is to be able to configure whether or not to discard all other B-legs on receiving media but on receiving an final code like 200. This way we will still get the first media that arrived but provide an answer on the actual channel that provided the 200.
 
My request comes from 2 sides, one commercial and the other personal. For the commercial I just need to now whether it is possible by some tweaking so the functionality can be offered.
 
The other, I've been involved in FS as a user from the very beginning (although I was absent for some time), and I'd like to help in the development of the project by letting the community know what's out there commercially speaking.
 
 
Hope you can help.
 
David

On Thu, Jan 14, 2010 at 5:26 PM, Anthony Minessale <anthony.minessale@gmail.com> wrote:
David,

Your request is somewhat challenging because we have to make sure FreeSWITCH is agnostic in protocols and that aside, we also have a very complicated and feature-rich originate API that does not currently support sending audio from one leg to the A leg while it's trying to call 10 other B legs.  Please try to understand that this request is a very special side case and we would have to do many hours of work to make it possible.  I am not sure if you are simply asking if its possible or if you want us to implement it for you but I am afraid it would fall under commercial support to undertake that unique of a feature that only helps a very small percentage of our user base considering all the work we already have to do every day.




On Thu, Jan 14, 2010 at 10:22 AM, Anthony Minessale <anthony.minessale@gmail.com> 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-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
GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888@conference.freeswitch.org
iax:guest@conference.freeswitch.org/888
googletalk:conf+888@conference.freeswitch.org
pstn:+19193869900



--
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
GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888@conference.freeswitch.org
iax:guest@conference.freeswitch.org/888
googletalk:conf+888@conference.freeswitch.org
pstn:+19193869900

_______________________________________________
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