Re: [Freeswitch-users] mod_callcenter agent may stuck "In a queue call" forever
Hi. I faced a problem with mod call centre strange behaviour. I have a queue with the strategy "ring all", queue has got 30 agents, all of them always have status available, but only 6 agents can be really active (e.g.: registered and connected) at a time. Those 6 simultaneously answer calls (e.g. can answer 200 on the same INVITE request before CANCEL arrives). *Sometimes an agent might get stuck in the state "In a queue call"* while he is not in a call. In that case waiting agent stops getting calls. CLI command:
*callcenter_config agent set state <agent> waiting*
changes state of an agent at DB, but call center still won't offer calls to him. The only fix I found is to reload mod_callcenter, but during reload all active calls would be dropped. Calls are coming one by one (maximum call rate I had ever seen at this site was ~600 calls/hour). But I didn't notice any correlation with the call rate. Agent may get stuck at any time of day with any call rate ranging between ~150 calls/hour to 400 calls/hour. Most of calls last from 5 to 20 seconds. I tried to switch from sqlite to odbc postgresql, but that changed nothing. Currently switch is connected to ODBC Postgresql. *OS version:* Linux local.pbx 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u4 (2016-02-29) x86_64 GNU/Linux *FS version:* FreeSWITCH version: 1.6.6+git~20160111T201612Z~d2d0b3283a~64bit (git d2d0b32 2016-01-11 20:16:12Z 64bit) *sqlite package:* llibsqlite3-0:amd64 3.8.7.1-1+deb8u1 amd64 SQLite 3 shared library *PostgreSQL / ODBC packages:* odbc-postgresql:amd64 1:09.03.0300-1 amd64 ODBC driver for PostgreSQL postgresql-9.4 9.4.6-0+deb8u1 amd64 object-relational SQL database, version 9.4 server *XML configs:* *callcenter/queues/queue.xml:*<queue name="dispatchers"> <param name="discard-abandoned-after" value="300"/> <param name="max-wait-time" value="0"/> <param name="max-wait-time-with-no-agent" value="120"/> <param name="moh-sound" value="$${hold_music}"/> <param name="strategy" value="ring-all"/> <param name="tier-rule-no-agent-no-wait" value="false"/> <param name="tier-rule-wait-multiply-level" value="true"/> <param name="tier-rule-wait-second" value="300"/> <param name="tier-rules-apply" value="false"/> <param name="time-base-score" value="queue"/> </queue> *callcenter/agents/agent.xml* <agent name="agent@local" type="callback" contact="user/agent@local" status="Available" max-no-answer="0" wrap-up-time="1" reject-delay-time="1" busy-delay-time="1" no-answer-delay-time="1"/> that's a typical agent. They are all same except name and contact attributes. *callcenter/tiers/tier.xml* <tier agent="agent@local" queue="dispatchers" level="1" position="1"/>
Can you file a JIRA with your debug logs please? Ítalo Rossi italo@freeswitch.org IRC chat.freenode.net #freeswitch #freeswitch-dev Bugs? https://freeswitch.org/jira Docs? https://freeswitch.org/jira Chat? https://hipchat.freeswitch.org/gUdAgy0m6
On Mar 24 2016, at 1:32 pm, TNTClaus <tntclaus@gmail.com> wrote:
Hi.
I faced a problem with mod call centre strange behaviour. I have a queue with the strategy "ring all", queue has got 30 agents, all of them always have status available, but only 6 agents can be really active (e.g.: registered and connected) at a time. Those 6 simultaneously answer calls (e.g. can answer 200 on the same INVITE request before CANCEL arrives). **Sometimes an agent might get stuck in the state "In a queue call"** while he is not in a call. In that case waiting agent stops getting calls. CLI command: > _callcenter_config agent set state <agent> waiting_
changes state of an agent at DB, but call center still won't offer calls to him. The only fix I found is to reload mod_callcenter, but during reload all active calls would be dropped.
Calls are coming one by one (maximum call rate I had ever seen at this site was ~600 calls/hour). But I didn't notice any correlation with the call rate. Agent may get stuck at any time of day with any call rate ranging between ~150 calls/hour to 400 calls/hour. Most of calls last from 5 to 20 seconds. I tried to switch from sqlite to odbc postgresql, but that changed nothing. Currently switch is connected to ODBC Postgresql.
**OS version:** Linux local.pbx 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u4 (2016-02-29) x86_64 GNU/Linux
**FS version:** FreeSWITCH version: 1.6.6+git~20160111T201612Z~d2d0b3283a~64bit (git d2d0b32 2016-01-11 20:16:12Z 64bit)
**sqlite package:** llibsqlite3-0:amd64 3.8.7.1-1+deb8u1 amd64 SQLite 3 shared library
**PostgreSQL / ODBC packages:** odbc-postgresql:amd64 1:09.03.0300-1 amd64 ODBC driver for PostgreSQL postgresql-9.4 9.4.6-0+deb8u1 amd64 object-relational SQL database, version 9.4 server
**XML configs:
**
**callcenter/queues/queue.xml: **<queue name="dispatchers"> <param name="discard-abandoned-after" value="300"/> <param name="max-wait-time" value="0"/> <param name="max-wait-time-with-no-agent" value="120"/> <param name="moh-sound" value="$${hold_music}"/> <param name="strategy" value="ring-all"/> <param name="tier-rule-no-agent-no-wait" value="false"/> <param name="tier-rule-wait-multiply-level" value="true"/> <param name="tier-rule-wait-second" value="300"/> <param name="tier-rules-apply" value="false"/> <param name="time-base-score" value="queue"/> </queue>**
**
**callcenter/agents/agent.xml** <agent name="agent@local" type="callback" contact="user/agent@local" status="Available" max-no-answer="0" wrap-up-time="1" reject-delay-time="1" busy-delay-time="1" no-answer-delay-time="1"/>** **
that's a typical agent. They are all same except name and contact attributes.
**callcenter/tiers/tier.xml** <tier agent="agent@local" queue="dispatchers" level="1" position="1"/>
Sorry, but it would be very hard to collect logs at the current production environment as this issue may happen once for several thousand calls. We will have to wait for long time and won't know exact time when an agent got stuck. All I can say is that this may happen when multiple agents try to accept the same call. I think this might be a bug or inappropriate behaviour of the switch, not mod_callcenter. We solved that problem with developing of custom system that decides whether to allow certain agent to accept call or not thus preventing multiple agents from sending 200 OK Response to an INVITE Request. I have a question. Is it normal when a hunt group, or callcenter queue with ringall strategy, where multiple agents replied 200 OK at the very same time, all will receive ACKs? Right after that in most cases all but one will receive BYE. But sometimes some agents may not receive BYE. How do determine that the call was actually started in such circumstances? It seems for me that that is the real issue (I mean absence of BYE request). And it is easy to reproduce: 1. Start two dummy sipuas united to one hunt group; 2. make them automatically accept an incoming call at the same time and start placing calls to their hunt group; 3. 10 calls would be enough to see the problem. Ofc it would be good to have wireshark logging at the same time. 2016-03-25 3:46 GMT+03:00 Ítalo Rossi <italo@freeswitch.org>:
Can you file a JIRA with your debug logs please?
Ítalo Rossi italo@freeswitch.org IRC chat.freenode.net #freeswitch #freeswitch-dev Bugs? https://freeswitch.org/jira Docs? https://freeswitch.org/jira Chat? https://hipchat.freeswitch.org/gUdAgy0m6
On Mar 24 2016, at 1:32 pm, TNTClaus <tntclaus@gmail.com> wrote:
Hi.
I faced a problem with mod call centre strange behaviour. I have a queue with the strategy "ring all", queue has got 30 agents, all of them always have status available, but only 6 agents can be really active (e.g.: registered and connected) at a time.
Those 6 simultaneously answer calls (e.g. can answer 200 on the same INVITE request before CANCEL arrives). *Sometimes an agent might get stuck in the state "In a queue call"* while he is not in a call. In that case waiting agent stops getting calls.
CLI command:
*callcenter_config agent set state <agent> waiting*
changes state of an agent at DB, but call center still won't offer calls to him. The only fix I found is to reload mod_callcenter, but during reload all active calls would be dropped.
Calls are coming one by one (maximum call rate I had ever seen at this site was ~600 calls/hour). But I didn't notice any correlation with the call rate. Agent may get stuck at any time of day with any call rate ranging between ~150 calls/hour to 400 calls/hour.
Most of calls last from 5 to 20 seconds.
I tried to switch from sqlite to odbc postgresql, but that changed nothing. Currently switch is connected to ODBC Postgresql.
*OS version:* Linux local.pbx 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u4 (2016-02-29) x86_64 GNU/Linux
*FS version:* FreeSWITCH version: 1.6.6+git~20160111T201612Z~d2d0b3283a~64bit (git d2d0b32 2016-01-11 20:16:12Z 64bit)
*sqlite package:* llibsqlite3-0:amd64 3.8.7.1-1+deb8u1 amd64 SQLite 3 shared library
*PostgreSQL / ODBC packages:* odbc-postgresql:amd64 1:09.03.0300-1 amd64 ODBC driver for PostgreSQL postgresql-9.4 9.4.6-0+deb8u1 amd64 object-relational SQL database, version 9.4 server
*XML configs:*
*callcenter/queues/queue.xml:*<queue name="dispatchers"> <param name="discard-abandoned-after" value="300"/> <param name="max-wait-time" value="0"/> <param name="max-wait-time-with-no-agent" value="120"/> <param name="moh-sound" value="$${hold_music}"/> <param name="strategy" value="ring-all"/> <param name="tier-rule-no-agent-no-wait" value="false"/> <param name="tier-rule-wait-multiply-level" value="true"/> <param name="tier-rule-wait-second" value="300"/> <param name="tier-rules-apply" value="false"/> <param name="time-base-score" value="queue"/> </queue>
*callcenter/agents/agent.xml* <agent name="agent@local" type="callback" contact="user/agent@local" status="Available" max-no-answer="0" wrap-up-time="1" reject-delay-time="1" busy-delay-time="1" no-answer-delay-time="1"/>
that's a typical agent. They are all same except name and contact attributes.
*callcenter/tiers/tier.xml* <tier agent="agent@local" queue="dispatchers" level="1" position="1"/>
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- С уважением, Клаус
participants (2)
-
TNTClaus
-
Ítalo Rossi