[Freeswitch-users] Another fifo request

[Matthew Fong]

Hi Anthony,
So it's been 2 days since my last request, so I'm due for another one ;)

It would be nice if there was a way to execute a script (lua) on fifo
bridge. I currently rely on the channel_bridge event, but I'm worried that
as my system scales, it would be better to fire a custom event. In non-fifo
mode, I can do this with bridge_pre_execute_bleg_app/data, but this doesn't
work with a fifo bridge. It doesn't really matter which channel it fires on
fifo out or fifo in channel, anything is better than having to listen for a
specific channel_bridge on a high-use FS installation.

Is there anyway to get an api/script to fire on fifo bridge currently that
I'm missing? Thanks!

--matt

2009/3/23 Anthony Minessale <anthony.minessale at gmail.com>

> ok,
> maybe after this i can have a day off ;)
>
> 2 variables added to latest trunk:
>
> "fifo_caller_consumer_import"
> "fifo_consumer_caller_import"
>
> both work like the regular import but one is a list of vars to copy from
> caller to consumer and one is a list to copy from consumer to caller.
>
>
> 2009/3/23 Matthew Fong <reply at matthewfong.com>
>
>> Thanks Anthony, for creating the transfer_after_bridge feature for me.
>> Your rapid actions, are the reason I'm positive I made the right decision
>> switch to to FS.
>> I got another challenge to throw your way. In the current fifo
>> implementation, there's no way to identify which fifo consumer, consumes a
>> caller--besides using other_leg_unique_id on bridge (ie, there's no way to
>> pass data between channels when a fifo bridge is created). I want to be able
>> to transfer some caller information to the consumer channel on bridge, to
>> populate an agent's screen.
>>
>> Under normal (non-fifo) circumstances, when a call is bridged, I've used
>> the 'import' channel variable, so that onBridge, the aleg automatically gets
>> populated with the bleg's 'import' field. However when fifo bridges, it does
>> not recognize import. In other applications, I've gotten around this by
>> using bridge_pre_execute_bleg_app/data to throw a custom event but with
>> fifo, bridge_pre_execute also does not work. I've been looking at the
>> fifo::info event, but again, there's no fifo_action that directly links
>> caller variables and consumer variables together.
>>
>> For now at least, I can get around this by storing uuid information in my
>> separate database, and looking up the other channel's information based
>> on other_leg_unique_id, but it would be nice if I could directly see it when
>> the channel is bridged. Anyway, great program, and I hope you consider
>> implementing these features to make FS even better. Thanks.
>>
>> --matt
>>
>>
>>
>> _______________________________________________
>> 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
>>
>>
>
>
> --
> Anthony Minessale II
>
> FreeSWITCH http://www.freeswitch.org/
> ClueCon http://www.cluecon.com/
>
> AIM: anthm
> MSN:anthony_minessale at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
> IRC: irc.freenode.net #freeswitch
>
> FreeSWITCH Developer Conference
> sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
> iax:guest at conference.freeswitch.org/888
> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
> pstn:213-799-1400
>
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20090326/f7b81407/attachment-0002.html