VoIP Mailing List Archives

[mattdfong at gmail.com]

I tried using fifo in an environment with about 9 agents last week, but ran into some issues, that I'm trying to piece together. The system is setup on a new ubuntu 64-bit machine and it should be plenty fast to handle this load. The delay does not occur when testing with a single agent...so it's hard for me to replicate on my vmware-based development machine, but thought I'd toss this out to the community to see if anyone has any suggestions

I'm using fifo in the reverse sense, in that my "agents" are put into a fifo, and an outbound call (a "contact") take an agent out of the fifo once the call is answered. I did this because it is an outbound call center, not an inbound one, and in reality I have agents waiting for a contact...not callers waiting for an agent.


Anyway, on about all my calls the logs indicate (and the agents I'm working with confirm), it appears to be taking > 5 seconds to actually bridge a call once the outbound "contact" channel is answered by FS and the channel takes an agent out of the fifo. I've attached a snipet of the fs.log and the dialplan below. But from timestamps it appears the delay is caused somewhere between these EXECUTE commands


EXECUTE sofia/external/1XXX4951027 set_user(default@)
EXECUTE sofia/external/1XXX4951027 db(insert/-spymap/1800XXX8234/aa763964-2933-11de-bbea-318f8f194b60)
EXECUTE sofia/external/1XXX4951027 db(insert/-last_dial/1800XXX8234/1990)
EXECUTE sofia/external/1XXX4951027 db(insert/-last_dial/global/aa763964-2933-11de-bbea-318f8f194b60)
EXECUTE sofia/external/1XXX4951027 answer()
EXECUTE sofia/external/1XXX4951027 set(fifo_caller_consumer_import=hh_stomp,hh_user)


when I looked at this..nothing pops out as out of the ordinary, that should cause >5 seconds delay. Your thoughts please ..


Thanks.


--matt


Full Log:
2009-04-14 16:35:18 [DEBUG] mod_sofia.c:173 sofia_on_execute() sofia/external/1XXX4951027 SOFIA EXECUTE
2009-04-14 16:35:18 [DEBUG] switch_core_state_machine.c:151 switch_core_standard_on_execute() sofia/external/1XXX4951027 Standard EXECUTE
EXECUTE sofia/external/1XXX4951027 set(open=true)
2009-04-14 16:35:18 [DEBUG] mod_dptools.c:748 set_function() sofia/external/1XXX4951027 SET [open]=[true]
EXECUTE sofia/external/1XXX4951027 set(use_profile=default)
2009-04-14 16:35:18 [DEBUG] mod_dptools.c:748 set_function() sofia/external/1XXX4951027 SET [use_profile]=[default]
EXECUTE sofia/external/1XXX4951027 set_user(default@)
EXECUTE sofia/external/1XXX4951027 db(insert/-spymap/1800XXX8234/aa763964-2933-11de-bbea-318f8f194b60)
EXECUTE sofia/external/1XXX4951027 db(insert/-last_dial/1800XXX8234/1990)
EXECUTE sofia/external/1XXX4951027 db(insert/-last_dial/global/aa763964-2933-11de-bbea-318f8f194b60)
EXECUTE sofia/external/1XXX4951027 answer()
EXECUTE sofia/external/1XXX4951027 set(fifo_caller_consumer_import=hh_stomp,hh_user)
2009-04-14 16:35:42 [DEBUG] mod_dptools.c:748 set_function() sofia/external/1XXX4951027 SET [fifo_caller_consumer_import]=[hh_stomp,hh_user]
EXECUTE sofia/external/1XXX4951027 set(fifo_consumer_exit_key=5)
2009-04-14 16:35:42 [DEBUG] mod_dptools.c:748 set_function() sofia/external/1XXX4951027 SET [fifo_consumer_exit_key]=[5]
EXECUTE sofia/external/1XXX4951027 fifo(2 out wait undef undef)
2009-04-14 16:35:42 [DEBUG] switch_channel.c:182 switch_channel_audio_sync() sofia/external/1XXX4951027 receive message [AUDIO_SYNC]
2009-04-14 16:35:43 [DEBUG] switch_ivr_bridge.c:911 switch_ivr_multi_threaded_bridge() sofia/external/1XXX4951027 receive message [BRIDGE]




Dialplan that Inbound "Contact" Calls are placed in
    <extension name="1990"><!--ag_incoming_q-->
      <condition field="destination_number" expression="^1990$">
        <action application="answer"/>
        <action application="set" data="fifo_caller_consumer_import=hh_stomp,hh_user"/>
        <action application="set" data="fifo_consumer_exit_key=5"/>
        <action application="fifo" data="${ag_qcall} out wait undef ${ag_dnc_msg}"/>
      </condition>
    </extension>





Dialplan for "my" Agent Calls:
    <extension name="1992"><!--ag_wait-->
      <condition field="destination_number" expression="^1992$">
        <action application="playback" data="hh/hh-doorbell.wav"/>
        <action application="fifo" data="${ag_qcall} in currency/dollars.wav $${hold_music}"/>
      </condition>
    </extension>

[anthony.minessale at g...]

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.



On Sun, Apr 19, 2009 at 12:08 AM, Matthew Fong <mattdfong@gmail.com (mattdfong@gmail.com)> wrote:

[brian at freeswitch.org]

Update rev. 13094 makes it not do wrap up on nowait.

/b

On Apr 20, 2009, at 8:02 AM, Anthony Minessale wrote:

[mattdfong at gmail.com]

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

On Tue, Apr 21, 2009 at 9:23 AM, Brian West <brian@freeswitch.org (brian@freeswitch.org)> wrote:

[mattdfong at gmail.com]

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 (mattdfong@gmail.com)> wrote:

[anthony.minessale at g...]

There was never really a problem it was just a minor behavioral change.

If you have it in production and need such careful support,
you should send an email to consulting@freeswitch.org (consulting@freeswitch.org) and sign up for a commercial support contract.



On Tue, Apr 21, 2009 at 12:37 AM, Matthew Fong <mattdfong@gmail.com (mattdfong@gmail.com)> wrote: