[Freeswitch-users] Avoiding restart of transfer_ringback file during successive bridge actions.

[Rupa Schomaker]

Maybe set a var that, when set, causes the dp to skip restarting the
ringback?

On Sun, Jan 10, 2010 at 11:00 PM, mayamatakeshi <mayamatakeshi at gmail.com>wrote:

> Hi,
> I'm implementing ACD functionality using a dialplan.
> Basically, I prepare a list of members in a group and try each one of them
> in successive bridge actions.
> I cannot use a single bridge action with all members separated with pipes
> because I am required to check some conditions like if the member is already
> in another call. So what I do is to add a transfer action after the bridge
> so that the call reenters the dialplan with the remaining of the list.
> Up to this point things are fine.
> However, if the call is answered and transferred to the group, I set
> transfer_ringback so that I can play a file while the bridge is happening.
> In case transfer_ringback is set to something like "local_stream://moh",
> then we hear a small glitch every time a bridge action happens as the bridge
> doesn't take into account that the ringback was already set up by a previous
> operation and sets up the playfile operation again. But this is also fine.
> The problem is in case transfer_ringback is set to an actual file and not
> local_stream. In this case, every bridge action will cause restart of the
> playback from the beginning.
> So, is it possible to ask bridge to do not setup playback if it is already
> running referencing the same file?
>
> regards,
> takeshi
>
>
>
>
>
> _______________________________________________
> 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
>
>


-- 
-Rupa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20100111/a36ea4a1/attachment-0002.html