[Home]

Summary:ASTERISK-23259: Local channel agent is unavailable for 5 seconds after login
Reporter:Benjamin Keith Ford (bford)Labels:
Date Opened:2014-02-06 14:51:24.000-0600Date Closed:
Priority:MajorRegression?
Status:Open/NewComponents:Applications/app_agent_pool
Versions:12.0.0 13.18.4 Frequency of
Occurrence
Constant
Related
Issues:
is duplicated byASTERISK-24268 ${QUEUE_MEMBER(uut_queue,free)} still = 0 when agent logged in
Environment:Attachments:
Description:When an agent logs in, that agent is unavailable for 5 seconds directly afterwards. This causes AgentRequest() to see the agent's state as 'Busy'.
Comments:By: Richard Mudgett (rmudgett) 2014-02-06 17:08:27.843-0600

After the five seconds are up the agent is available and the state should be 'Idle'.

By: Richard Mudgett (rmudgett) 2014-02-07 10:52:54.012-0600

Relevant code in app_agent_pool.c:bridge_agent_hold_push():
{code}
case AGENT_STATE_LOGGED_OUT:
/*!
* \todo XXX the login probation time should be only if it is needed.
*
* Need to determine if there are any local channels that can
* optimize and wait until they actually do before leaving the
* AGENT_STATE_PROBATION_WAIT state.  For now, the blind
* timer of LOGIN_WAIT_TIMEOUT_TIME will do.
*/
/*
* Start the login probation timer.
*
* We cannot handle an agent local channel optimization when the
* agent is on a call.  The optimization may kick the agent
* channel we know about out of the call without our being able
* to switch to the replacement channel.  Get any agent local
* channel optimization out of the way while the agent is in the
* holding bridge.
*/
time(&agent->probation_start);
agent->state = AGENT_STATE_PROBATION_WAIT;
agent_unlock(agent);
break;
{code}


By: Matt Jordan (mjordan) 2014-08-12 11:06:22.137-0500

That doesn't mean this is a good thing to do. From the perspective of an end user, there's no reason why this should be the case.

By: Abhay Gupta (agupta) 2016-02-18 08:03:30.994-0600

Will this be changed or can we set it to 0 sec or 5 second is must .

By: Richard Mudgett (rmudgett) 2016-02-18 11:18:45.139-0600

From the timestamps on the issue and earlier comments, fixing this is not a priority.  You could change the LOGIN_WAIT_TIMEOUT_TIME define in the code to zero on your installation *only if* you never have an agent login using a local channel.  As stated in the code comment above, the probation wait time is necessary to allow any local channels a chance to optimize out.

When used with the Queue() application, the agent will not receive calls while in the 5 second probation period.  The agent's device state is UNAVAILABLE until the probation period ends when the device state becomes IDLE.