[asterisk-dev] New agents does not get noted for waiting callers in the queue

Kristijan Vrban vrban.lkml at googlemail.com
Mon Feb 13 10:33:10 CST 2012


Sure, the non polling solution would be the preferred. But the polling
solution by adding the "load_realtime_queue" into "is_our_turn"
function would be an
acceptable quick fix solution. But the issues, that the audio get
dropout while doing some functional queue processing (make a sql
loopkup) irritated me.
Why depend audio processing from what the queue do? Because that
means, even if the queue does "normal" things, this can always be the
source of audio dropout.
e.g. add a sleep(1) into "is_our_turn" function, then you have 1sec
audio dropout.

Without know the hole asterisk structural, but shouldn't be the audio
processing independent from any logical processing?

Kristijan

2012/2/13 Kevin P. Fleming <kpfleming at digium.com>:
> On 02/13/2012 04:58 AM, Kristijan Vrban wrote:
>>
>> Hello, a customer criticised that when one or more caller are waiting
>> in a queue (i use realtime queues) to get a free agent, and a new
>> agent logged in,
>> the new agent does not get the callers which are wating in the queue.
>> Beacause when a caller enters the queue, the lookup which agents are
>> available, passed only once when the caller enters the queue.
>>
>> So i made a simple hack, i added the "load_realtime_queue" function
>> into "is_our_turn" which was the solution. Not a beauty, because every
>> caller wainting
>> in a queue produced in every run of "is_our_turn" a new database
>> lookup. It would be lovelier, if there is one globel thread for the
>> one queue that renew
>> ,in a configurable interval, the available queue agents.
>
>
> And the result would be non-realtime-queues... you'll be caching the queue
> and its member list in memory at all times, and forcing app_queue to
> constantly poll the database to see if it has changed. As you've already
> noted, this will likely cause performance problems.
>
>
>> But the main problem i got stuck, plenty of times the caller get Moh
>> dropout when "load_realtime_queue" get called in the "is_our_turn"
>> function.
>> As described in:
>> https://issues.asterisk.org/jira/browse/ASTERISK-18989 I reckon that
>> "load_realtime_queue" set some locks, which caused the
>> res_timing_timerfd
>> and res_rtp_asterisk issues as seen in the debug log which reason the
>> Moh dropout.
>>
>> Question: how to design a function for app_queue that the new agents
>> get noted? suggestions?
>
>
> If such a function existed, how would it get triggered? There are only two
> options: either app_queue polls the realtime storage, or something tells
> app_queue to reload its configuration when it has been changed via some
> external mechanism. If that 'something' can tell app_queue to reload, then
> it should; that will always be far more efficient than polling the realtime
> storage for changes.
>
> --
> Kevin P. Fleming
> Digium, Inc. | Director of Software Technologies
> Jabber: kfleming at digium.com | SIP: kpfleming at digium.com | Skype: kpfleming
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> Check us out at www.digium.com & www.asterisk.org
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>  http://lists.digium.com/mailman/listinfo/asterisk-dev



More information about the asterisk-dev mailing list