Double Queue Calls Being Delivered To Agents

Home » Asterisk Users » Double Queue Calls Being Delivered To Agents
Asterisk Users 6 Comments

I posted this over in asterisk-dev, realized I probably should have put it here.

Hi there, We’ve been having a strange issue with a customer’s queues where a queued call will ring an available agent, agent answers, then a second or two later the agent is offered a second call which they cannot answer, since they’re already speaking with a client.

This in turn causes a few issues:
– Agent stats are no longer accurate, as it gets marked down as a ‘missed call’.
– Cannot use ‘autopause’ feature any longer, as the second queue call goes unanswered and pauses the agents.

The basic queue setup is as follows:
Autofill = yes Ringinuse = no Wrapuptime = 5
Strategy = fewestcalls (tried ‘random’ also)
Timeout = 15

We’re on Asterisk 11.21.2 currently.

In talking to a few colleagues, they seem to recall there being an old patch for the Asterisk queues application that inserted a short 100ms delay between delivering first and second calls. I’ve scoured the web today, and found some old forums posts of people looking for something exactly like this, but haven’t found the actual patch, if one even exists.

I’m hoping someone may have some suggestions on some options we can try to eliminate this issue.

Thanks for taking the time to read this.

-Derek B
—

6 thoughts on - Double Queue Calls Being Delivered To Agents

  • I took a look through Asterisk 11 and 13 change logs but didn’t see any mention of that patch/fix. Am I missing something?

    Derek B

  • Sorry for last post — forgot to wipe out the digest contents :/

    Derek B

  • Looks like it will be in the next release as the issue does not have a target release set.

    Richard

  • Awesome. Thanks again Richard.

    I posted this over in asterisk-dev, realized I probably should have put it here.

    Hi there, We’ve been having a strange issue with a customer’s queues where a queued call will ring an available agent, agent answers, then a second or two later the agent is offered a second call which they cannot answer, since they’re already speaking with a client.

    This in turn causes a few issues:
    – Agent stats are no longer accurate, as it gets marked down as a ‘missed call’.
    – Cannot use ‘autopause’ feature any longer, as the second queue call goes unanswered and pauses the agents.

    The basic queue setup is as follows:
    Autofill = yes Ringinuse = no Wrapuptime = 5
    Strategy = fewestcalls (tried ‘random’ also)
    Timeout = 15

    We’re on Asterisk 11.21.2 currently.

    In talking to a few colleagues, they seem to recall there being an old patch for the Asterisk queues application that inserted a short 100ms delay between delivering first and second calls. I’ve scoured the web today, and found some old forums posts of people looking for something exactly like this, but haven’t found the actual patch, if one even exists.

    I’m hoping someone may have some suggestions on some options we can try to eliminate this issue.

    Thanks for taking the time to read this.

    This issue has been around a long time and was just recently fixed and I think it was just released in the latest v11 version. See https://issues.asterisk.org/jira/browse/ASTERISK-16115

    Looks like it will be in the next release as the issue does not have a target release set.

    Richard

  • TG9va3MgbGlrZSBpdCBtaXNzZWQgMTMuOS4wIOKYuQ0KDQpUaGFua3MsDQpEZXJlayBCLg0KDQpG
    cm9tOiBhc3Rlcmlzay11c2Vycy1ib3VuY2VzQGxpc3RzLmRpZ2l1bS5jb20gW21haWx0bzphc3Rl cmlzay11c2Vycy1ib3VuY2VzQGxpc3RzLmRpZ2l1bS5jb21dIE9uIEJlaGFsZiBPZiBSaWNoYXJk IE11ZGdldHQNClNlbnQ6IFdlZG5lc2RheSwgTWF5IDA0LCAyMDE2IDEwOjU5IFBNDQpUbzogQXN0
    ZXJpc2sgVXNlcnMgTWFpbGluZyBMaXN0IC0gTm9uLUNvbW1lcmNpYWwgRGlzY3Vzc2lvbiA8YXN0
    ZXJpc2stdXNlcnNAbGlzdHMuZGlnaXVtLmNvbT4NClN1YmplY3Q6IFJlOiBbYXN0ZXJpc2stdXNl cnNdIERvdWJsZSBxdWV1ZSBjYWxscyBiZWluZyBkZWxpdmVyZWQgdG8gYWdlbnRzDQoNCg0KDQpP
    biBUdWUsIE1heSAzLCAyMDE2IGF0IDg6NTkgUE0sIFJpY2hhcmQgTXVkZ2V0dCA8cm11ZGdldHRA
    ZGlnaXVtLmNvbTxtYWlsdG86cm11ZGdldHRAZGlnaXVtLmNvbT4+IHdyb3RlOg0KDQoNCk9uIFR1
    ZSwgTWF5IDMsIDIwMTYgYXQgNjoxNSBQTSwgRGVyZWsgQm9saWNob3dza2kgPGRlcmVrQGVtcGly ZS10ZWFtLmNvbTxtYWlsdG86ZGVyZWtAZW1waXJlLXRlYW0uY29tPj4gd3JvdGU6DQpJIHBvc3Rl ZCB0aGlzIG92ZXIgaW4gYXN0ZXJpc2stZGV2LCByZWFsaXplZCBJIHByb2JhYmx5IHNob3VsZCBo YXZlIHB1dCBpdCBoZXJlLg0KDQpIaSB0aGVyZSwNCldl4oCZdmUgYmVlbiBoYXZpbmcgYSBzdHJh bmdlIGlzc3VlIHdpdGggYSBjdXN0b21lcuKAmXMgcXVldWVzIHdoZXJlIGEgcXVldWVkIGNhbGwg d2lsbCByaW5nIGFuIGF2YWlsYWJsZSBhZ2VudCwgYWdlbnQgYW5zd2VycywgdGhlbiBhIHNlY29u ZCBvciB0d28gbGF0ZXIgdGhlIGFnZW50IGlzIG9mZmVyZWQgYSBzZWNvbmQgY2FsbCB3aGljaCB0
    aGV5IGNhbm5vdCBhbnN3ZXIsIHNpbmNlIHRoZXnigJlyZSBhbHJlYWR5IHNwZWFraW5nIHdpdGgg YSBjbGllbnQuDQoNClRoaXMgaW4gdHVybiBjYXVzZXMgYSBmZXcgaXNzdWVzOg0KLSBBZ2VudCBz dGF0cyBhcmUgbm8gbG9uZ2VyIGFjY3VyYXRlLCBhcyBpdCBnZXRzIG1hcmtlZCBkb3duIGFzIGEg
    4oCYbWlzc2VkIGNhbGzigJkuDQotIENhbm5vdCB1c2Ug4oCYYXV0b3BhdXNl4oCZIGZlYXR1cmUg YW55IGxvbmdlciwgYXMgdGhlIHNlY29uZCBxdWV1ZSBjYWxsIGdvZXMgdW5hbnN3ZXJlZCBhbmQg cGF1c2VzIHRoZSBhZ2VudHMuDQoNClRoZSBiYXNpYyBxdWV1ZSBzZXR1cCBpcyBhcyBmb2xsb3dz Og0KQXV0b2ZpbGwgPSB5ZXMNClJpbmdpbnVzZSA9IG5vDQpXcmFwdXB0aW1lID0gNQ0KU3RyYXRl Z3kgPSBmZXdlc3RjYWxscyAodHJpZWQg4oCYcmFuZG9t4oCZIGFsc28pDQpUaW1lb3V0ID0gMTUN
    Cg0KV2XigJlyZSBvbiBBc3RlcmlzayAxMS4yMS4yIGN1cnJlbnRseS4NCg0KSW4gdGFsa2luZyB0
    byBhIGZldyBjb2xsZWFndWVzLCB0aGV5IHNlZW0gdG8gcmVjYWxsIHRoZXJlIGJlaW5nIGFuIG9s ZCBwYXRjaCBmb3IgdGhlIEFzdGVyaXNrIHF1ZXVlcyBhcHBsaWNhdGlvbiB0aGF0IGluc2VydGVk IGEgc2hvcnQgMTAwbXMgZGVsYXkgYmV0d2VlbiBkZWxpdmVyaW5nIGZpcnN0IGFuZCBzZWNvbmQg Y2FsbHMuICBJ4oCZdmUgc2NvdXJlZCB0aGUgd2ViIHRvZGF5LCBhbmQgZm91bmQgc29tZSBvbGQg Zm9ydW1zIHBvc3RzIG9mIHBlb3BsZSBsb29raW5nIGZvciBzb21ldGhpbmcgZXhhY3RseSBsaWtl IHRoaXMsIGJ1dCBoYXZlbuKAmXQgZm91bmQgdGhlIGFjdHVhbCBwYXRjaCwgaWYgb25lIGV2ZW4g ZXhpc3RzLg0KDQpJ4oCZbSBob3Bpbmcgc29tZW9uZSBtYXkgaGF2ZSBzb21lIHN1Z2dlc3Rpb25z IG9uIHNvbWUgb3B0aW9ucyB3ZSBjYW4gdHJ5IHRvIGVsaW1pbmF0ZSB0aGlzIGlzc3VlLg0KDQpU
    aGFua3MgZm9yIHRha2luZyB0aGUgdGltZSB0byByZWFkIHRoaXMuDQoNClRoaXMgaXNzdWUgaGFz IGJlZW4gYXJvdW5kIGEgbG9uZyB0aW1lIGFuZCB3YXMganVzdCByZWNlbnRseSBmaXhlZCBhbmQg SSB0aGluaw0KaXQgd2FzIGp1c3QgcmVsZWFzZWQgaW4gdGhlIGxhdGVzdCB2MTEgdmVyc2lvbi4N
    ClNlZSBodHRwczovL2lzc3Vlcy5hc3Rlcmlzay5vcmcvamlyYS9icm93c2UvQVNURVJJU0stMTYx MTUNCg0KTG9va3MgbGlrZSBpdCB3aWxsIGJlIGluIHRoZSBuZXh0IHJlbGVhc2UgYXMgdGhlIGlz c3VlIGRvZXMgbm90IGhhdmUgYSB0YXJnZXQgcmVsZWFzZSBzZXQuDQpSaWNoYXJkDQoNCg=