Hi all
****EDIT: Got the examples mixed up in the first post.
I’ve got a major problem in Asterisk 13:
- Occasionally (perhaps 1 out of 10 calls), a call in first place in queue is not answered for quite some time, with other callers being answered
- The faulty call genereates multiple entries in CDR table for same call
- The final (billable) entry isn’t registered in CDR table.
Example from CLI>queue show:
XXX has 4 calls (max unlimited) in 'ringall' strategy (171s holdtime, 44s talktime), W:1000234, C:227, A:65, SL:0.0% within 0s
Members:
SIP/yyyy (ringinuse disabled) (realtime) (Ringing) has taken 59 calls (last was 1378 secs ago)
SIP/xxxx (ringinuse disabled) (realtime) (in call) (Busy) has taken 168 calls (last was 11 secs ago)
Callers:
1. SIP/x.x.x.x-000184ae (wait: 6:36, prio: 0)
2. SIP/x.x.x.x-000188ab (wait: 1:59, prio: 0)
3. SIP/x.x.x.x-00018a0f (wait: 0:32, prio: 0)
Shortly afterwards, SIP/xxxx takes the next call, but it’s actually nr. 2 that gets answered. Repeated CLI>queue show:
XXX has 5 calls (max unlimited) in 'ringall' strategy (166s holdtime, 41s talktime), W:1000234, C:228, A:66, SL:0.0% within 0s
Members:
SIP/yyyy (ringinuse disabled) (realtime) (Ringing) has taken 59 calls (last was 1483 secs ago)
SIP/xxxx (ringinuse disabled) (realtime) (in call) (Busy) has taken 169 calls (last was 76 secs ago)
Callers:
1. SIP/x.x.x.x-000184ae (wait: 8:21, prio: 0)
2. SIP/x.x.x.x-00018a0f (wait: 2:17, prio: 0)
3. SIP/x.x.x.x-00018a10 (wait: 2:15, prio: 0)
Channel SIP/x.x.x.x-000184ae is still in the queue, but channel SIP/x.x.x.x-000188ab (which was in 2nd position) has been answered.
This continued for the next 7-8 minutes, until the sprung-over channel was finally answered.
The sprung over channel, SIP/x.x.x.x-000184ae, is different from the others when using CLI>core show channel command
The “faulty” channel has several levels of CDR variables, with one level being added for each queue timeout period. The other “normal” channels only have one level of CDR variables.
The “faulty” channel has (on all levels) the variable DSTCHANNEL set to SIP/yyyy (which was not taking calls at this time), so it seems to be stuck on calling only one of the two agents in the queue? None of the other channels had DSTCHANNEL set.
Once the call was answered and hungup, I checked the CDR table - there were 51 entries for the call (all with dstchannel = SIP/yyyy) but the billable, answered, call was not in the CDR table.