Hi Anthony & Brian,
I have not yet run r13094 in my production environment with live agents, so I cannot give you feedback (but hopefully I'll get a chance to put it into a live system in a few days)
but I re-reviewed the logs I had and I'm not convinced the issue I was having of a delayed bridge was related to the default fifo_consumer_wrapup_time. The reason is:
1) it's not a consistent 5 second delay in bridging...sometimes it's a 2 second delay, sometimes it's as high as a 38 second delay (I can provide logs if needed)
2) In my setup, each consumer (channel that executes fifo out) is always a "fresh/new" channel. My "consumers" do not get recycled, instead they get hungup at the end of the call (while my fifo ins get transferred to another extension, which puts them back into fifo in)
Are these problems still consistent with the issues that were fixed in r13094? I'm a little hesitant to put the system back in a live environment since the fix and diagnosis aren't 100% compatible. As always tho, thanks for the really quick fix and reply. Awesome telephone framework.
--matt
On Tue, Apr 21, 2009 at 9:53 AM, Matthew Fong
<mattdfong@gmail.com> wrote:
Thanks I'll check it out.
One more quick but related question.
Is there ever an instance when the audio is BRIDGED before the BRIDGE event is fired. Could this fifo issue have bridged audio immediately, but somehow withheld the bridge event from being fired for 5 seconds? A few of my callers were reporting they could hear the Contact, but the BRIDGE event (and my subsequent programming to popup the contact information on screen) was being delayed 5 seconds.
thanks !
--matt
Update rev. 13094 makes it not do wrap up on nowait.
/b
On Apr 20, 2009, at 8:02 AM, Anthony Minessale wrote:
it's probably the designed wrapup time for agents.
fifo_consumer_wrapup_time var controls this wait time in milliseconds and the default is 5 sec.