Hi,
We have a common scenario where a menu forwards a call to a feature code, which then puts the call into a queue. Typically this is because queues have timeouts or other custom behaviour.
When we do this, according to the queue log the call is hung up as soon as it is connected to the queue, although in actual fact the call continues as normal
Changing the menu to run the PBX command that the feature extension has the same functional result.
Can someone confirm this behaviour? I'm guessing it's an asterisk bug, but probably has quite a complicated fix. A simpler fix (for me) I think would be to have a new "Go to feature code" in the IVR menu that allowed executing a featurecode with a goto command, rather than a Dial command.
Andrew
There are entries in the
There are entries in the queue log; but I think that out of the box we should get the "expected" behaviour, which I think should be that the queue log correctly records the time in the queue - and so we should avoid dialing using chan_local.
Andrew
This is partly an asterisk
This is partly an asterisk core concern. I suspect you haven't investigated chan_agent thoroughly as it too uses chan_local to call extensions. When you add an agent as a queue member chan_agent connects to chan_local to reach your extension where chan_sip eventually handles the call. for what its worth, queuemetrics does manage to decipher the logs correctly despite all the entries. I DO agree that Go to feature extension should actually be a Goto not a Dial, because every Dial is another CDR entry for what should really be 1 entry per call as should be the case with user extensions.
you should have a couple queue log entries. You are correct on your assessment about the chan local behaviors. Once you find the correct uniqueID you can grep that id from the queue_log to see who answered and how long the call lasted.