Queue Hangups

Hi, I am getting the errors below even though the agent did not hang up.

Failed to write frame
– <Agent/5618> Playing ‘queue-reporthold’ (language ‘en’)
Agent on Agent/5618 hungup on the customer.

This occurs intermittently for any agent in any queue. Any help will be greatly appreciated!


REL 5.5
Asterisk 1.4.36
Dahdi 2.4.0

more detail on how agents are logged in to queues? can you provide the output from “queue show XXX” where XXX is the queue identifier? queue configuration would be nice too.

I believe that the problem is that dahdi_dummy is not loading which is causing a timing issue. Can anyone help me to get the module loaded?

[root@voip1 dahdi-linux-2.4.0]# service dahdi start
Loading DAHDI hardware modules:

No hardware timing source found in /proc/dahdi, loading dahdi_dummy
Running dahdi_cfg: [ OK ]
[root@voip1 dahdi-linux-2.4.0]# lsmod | grep dahdi
dahdi 238768 0
crc_ccitt 35265 1 dahdi
[root@voip1 dahdi-linux-2.4.0]# modprobe dahdi_dummy
[root@voip1 dahdi-linux-2.4.0]# lsmod | grep dahdi
dahdi 238768 0
crc_ccitt 35265 1 dahdi

Looks like the dahdi_dummy module is not getting installed during the make process. I am running REL 5.5.

I got it loaded by installing an older version. Used instead of 2.4.0.

Will submit another ticket for 2.4.0 not installing dahdi_dummy under REL 5.5.

2.4.0 with the default options shouldn’t need dahdi_dummy, as there is a fallback timing source in the core module (dahdi-base.c).

However, if you actually need libpri, you will have real dahdi hardware and shouldn’t need a dummy timing source.

Also, I don’t believe that a missing timing source will cause your symptoms - it tends to cause a lack of audio, particularly for generated tones, voice announcements, and MOH.

Hi mudslide567,

Agents login from their SIP Polycom phones using an extension that calls AgentLogin.
exten = 8000,1,AgentLogin()

Agents are defined in agents.conf and are members of multiple queues as defined in queues.conf.
from agents.conf
agent => 5101,1234,Joe

from queues.conf
fullname = Claims
strategy = rrmemory
timeout = 15
wrapuptime = 10
autofill = yes
autopause = no
maxlen =
joinempty = strict
leavewhenempty = no
reportholdtime = yes
musicclass =
announce = /var/lib/asterisk/sounds/record/Claims
member = Agent/5101

asterisk -rx “queue show 5901” | grep -v Unavailable

5901 has 0 calls (max unlimited) in ‘rrmemory’ strategy (20s holdtime), W:0, C:8, A:0, SL:37.5% within 0s
Agent/5210 (Busy) has taken 2 calls (last was 638 secs ago)
Agent/5209 (Not in use) has taken 6 calls (last was 550 secs ago)
No Callers


And david55 you were right. From the agents perspective they hear the Beep and sometimes the Announce and then no one is on the line. They then hit star a wait for the next incoming call. The problem is intermittent. An example as seen on the CLI is below.


e[1;36;40mGotoe[0;37;40m(“e[1;35;40mSIP/vitel-inbound-00000193e[0;37;40m”, “e[1;35;40mdefault|5901|1e[0;37;40m”) in new stack
e[0K – Goto (default,5901,1)
e[0K – Executing [5901@default:1] e[1;36;40mQueuee[0;37;40m(“e[1;35;40mSIP/vitel-inbound-00000193e[0;37;40m”, “e[1;35;40m5901e[0;37;40m”) in new stack
e[0K – Started music on hold, class ‘default’, on SIP/vitel-inbound-00000193
e[0K – agent_call, call to agent ‘5210’ call on 'SIP/5057-00000045’
e[0K – <SIP/5057-00000045> Playing ‘beep’ (language ‘en’)
e[0K – Agent/5210 answered SIP/vitel-inbound-00000193
e[0K – <Agent/5210> Playing ‘/var/lib/asterisk/sounds/record/Claims’ (language ‘en’)
e[0K[Dec 8 10:28:33] e[1;31;40mWARNINGe[0;37;40m[5446]: e[1;37;40mfile.ce[0;37;40m:e[1;37;40m765e[0;37;40m e[1;37;40mast_readaudio_callbacke[0;37;40m: Failed to write frame
– <Agent/5210> Playing ‘queue-reporthold’ (language ‘en’)
e[0K[Dec 8 10:28:33] e[1;31;40mWARNINGe[0;37;40m[5446]: e[1;37;40mapp_queue.ce[0;37;40m:e[1;37;40m3111e[0;37;40m e[1;37;40mtry_callinge[0;37;40m: Agent on Agent/5210 hungup on the customer.