Using Queue Priorities To Add Agents

Home » Asterisk Users » Using Queue Priorities To Add Agents
Asterisk Users 4 Comments

I have a scenario that I am failing to implement using the Queue app, but which I had thought would be commonplace…

First of all, I would like to recommend this short cookbook that offers recipes for tackling dialplan fundamentals, making and controlling calls, and monitoring channels in your PBX environment. Each recipe includes a simple code solution you can put to work immediately, along with a detailed discussion that offers insight into why and how the recipe works.

Many of the conventions and information presented are version-agnostic. These recipes include solutions to help you:

– Authenticate callers before moving on in your dialplan
– Redirect calls received by your auto-attendant
– Create an automatic call-back service
– Initiate hot-desking to login to and accept calls at any office device
– Monitor and interrupt live calls to train new employees at a call center
– Record calls from your Asterisk dialplan

Now, back to my problem:

1) (this bit works fine) I want a queue caller to have access to the basic set of agents initially, with an overflow to additional agents if they are busy – This is done using penalty:

queues.conf:
member => SIP/dev1,0,Agent1
member => SIP/dev2,0,Agent2
member => SIP/dev3,1,Agent3 is overflow

2) But, after 60 seconds, I want Agent 3 to be included whether the 1 and 2 are busy or not. None of the queue rules options seem to achieve this because regardless of which agents are included or not, the penalty used to group them is also penalizing them.

Help? Is what I want possible?

PS. I did consider hacking the meaning of QUEUE_MIN_PENALTY so that it actually increases lower penalties to it’s current value, thus putting them on an even footing, instead of blocking out agents.

Thanks, Steve

4 thoughts on - Using Queue Priorities To Add Agents

  • SWYgYWZ0ZXIgNjAgc2Vjb25kcyB5b3UgbWVhbiDigJk2MCBzZWNvbmRzIG9mIGNhbGxlciBob2xk IHRpbWXigJkgdGhlbiBzZXQgdXAgYW5vdGhlciBxdWV1ZSBhcyBvdmVyZmxvdywNCg0KU2V0IHRo ZSBmaXJzdCBxdWV1ZSB0byB0aW1lb3V0IGFmdGVyIDYwIHNlY3MuIFRoZW4gc2VuZCB0byB0aGUg b3ZlcmZsb3cgcXVldWUgd2l0aCBhbGwgYWdlbnRzL21lbWJlcnMgYXMgc2FtZSBwcmlvcml0eS4N
    Cg0KDQrigJxZb3UgY2FuIGVpdGhlciBmb2xsb3cgeW91ciBmZWFycyBvciBiZSBsZWQgYnkgeW91
    ciBwYXNzaW9ucywgaXRzIHVwIHRvIHlvdeKApuKApi4u4oCdDQoNCkFsZXhhbmRlciBMb3Bleg0K
    T3BTeXMgQ29uc3VsdGluZyBHcm91cA0KUE8gQm94IDQ5LTEzMzMNCktleSBCaXNjYXluZSwgRkwg MzMxNDkNClRlbDogMzA1IDUwMyAzMDAwIHggMTIyDQpNYWtpbmcgbGlmZSBoYXJkIGZvciBvdGhl cnMgc2luY2UgMTk3MC4NCg0KSGVscC1kZXNrOiAoMzA1KTUwMy0zMDAwIE9wdGlvbiAwIG9yDQpF
    bWFpbDogSGVscERlc2tAT3BTeXMuY29tPG1haWx0bzpIZWxwRGVza0BPcFN5cy5jb20+DQoNCg0K
    RnJvbTogYXN0ZXJpc2stdXNlcnMtYm91bmNlc0BsaXN0cy5kaWdpdW0uY29tIFttYWlsdG86YXN0
    ZXJpc2stdXNlcnMtYm91bmNlc0BsaXN0cy5kaWdpdW0uY29tXSBPbiBCZWhhbGYgT2YgU3RldmUg RGF2aWVzDQpTZW50OiBUaHVyc2RheSwgTWF5IDExLCAyMDE3IDc6MTggQU0NClRvOiBBc3Rlcmlz ayBVc2VycyBNYWlsaW5nIExpc3QgLSBOb24tQ29tbWVyY2lhbCBEaXNjdXNzaW9uIDxhc3Rlcmlz ay11c2Vyc0BsaXN0cy5kaWdpdW0uY29tPg0KU3ViamVjdDogW2FzdGVyaXNrLXVzZXJzXSBVc2lu ZyBxdWV1ZSBwcmlvcml0aWVzIHRvIGFkZCBhZ2VudHMNCg0KSGksDQoNCkkgaGF2ZSBhIHNjZW5h cmlvIHRoYXQgSSBhbSBmYWlsaW5nIHRvIGltcGxlbWVudCB1c2luZyB0aGUgUXVldWUgYXBwLCBi dXQgd2hpY2ggSSBoYWQgdGhvdWdodCB3b3VsZCBiZSBjb21tb25wbGFjZS4uLg0KDQoxKSAodGhp cyBiaXQgd29ya3MgZmluZSkgSSB3YW50IGEgcXVldWUgY2FsbGVyIHRvIGhhdmUgYWNjZXNzIHRv IHRoZSBiYXNpYyBzZXQgb2YgYWdlbnRzIGluaXRpYWxseSwgd2l0aCBhbiBvdmVyZmxvdyB0byBh ZGRpdGlvbmFsIGFnZW50cyBpZiB0aGV5IGFyZSBidXN5IC0gVGhpcyBpcyBkb25lIHVzaW5nIHBl bmFsdHk6DQoNCnF1ZXVlcy5jb25mOg0KbWVtYmVyID0+IFNJUC9kZXYxLDAsQWdlbnQxDQptZW1i ZXIgPT4gU0lQL2RldjIsMCxBZ2VudDINCm1lbWJlciA9PiBTSVAvZGV2MywxLEFnZW50MyBpcyBv dmVyZmxvdw0KDQoyKSBCdXQsIGFmdGVyIDYwIHNlY29uZHMsIEkgd2FudCBBZ2VudCAzIHRvIGJl IGluY2x1ZGVkIHdoZXRoZXIgdGhlIDEgYW5kIDIgYXJlIGJ1c3kgb3Igbm90LiBOb25lIG9mIHRo ZSBxdWV1ZXJ1bGVzIG9wdGlvbnMgc2VlbSB0byBhY2hpZXZlIHRoaXMgYmVjYXVzZSByZWdhcmRs ZXNzIG9mIHdoaWNoIGFnZW50cyBhcmUgaW5jbHVkZWQgb3Igbm90LCB0aGUgcGVuYWx0eSB1c2Vk IHRvIGdyb3VwIHRoZW0gaXMgYWxzbyBwZW5hbGlzaW5nIHRoZW0uDQoNCkhlbHA/IElzIHdoYXQg SSB3YW50IHBvc3NpYmxlPw0KDQpQUy4gSSBkaWQgY29uc2lkZXIgaGFja2luZyB0aGUgbWVhbmlu ZyBvZiBRVUVVRV9NSU5fUEVOQUxUWSBzbyB0aGF0IGl0IGFjdHVhbGx5IGluY3JlYXNlcyBsb3dl ciBwZW5hbHRpZXMgdG8gaXQncyBjdXJyZW50IHZhbHVlLCB0aHVzIHB1dHRpbmcgdGhlbSBvbiBh biBldmVuIGZvb3RpbmcsIGluc3RlYWQgb2YgYmxvY2tpbmcgb3V0IGFnZW50cy4NCg0KVGhhbmtz LA0KU3RldmUNCg0K

  • I have a real ugly queue that has this in it’s rules

    [mrule]
    penaltychange => 20,2,2
    penaltychange => 40,3,3
    penaltychange => 80,4,4
    penaltychange => 120,5,5
    penaltychange => 150,6,6
    penaltychange => 180,1,1
    penaltychange => 200,2,2
    penaltychange => 220,3,3
    penaltychange => 240,4,4
    penaltychange => 260,5,5
    penaltychange => 280,6,6
    penaltychange => 300,1,1

    [myqueue]
    member => SIP/100.2,1,Receptionist member => SIP/101.2,2,Kelli member => SIP/102.2,2,Traci member => SIP/103.2,3,Debi member => SIP/104.2,4,Debbie member => SIP/105.2,4,Luci member => SIP/106.2,5,Sheila member => SIP/107.2,6,Mike

    So every 20 seconds it jumps up to the next Penalty and every few minutes it resets the penalty back down to 1 and starts again.

  • Thanks for the suggestion – That is what is currently in place, but it allows queue-jumping as Asterisk does not know that one queue should be serviced (drained) before the other. That can be improved upon by doing a Waiting count on the 2nd queue etc etc, but there is always a q-jumping scenario unless the whole thing is managed inside a single queue.

    Cheers, Steve

  • Hi,

    Thanks for this suggestion – I believe it does not quite fit the requirement as follows:

    – When you move up to priority 2, you will stop ringing ‘Receptionist’ as they are out of scope penalty 1 < 2. – Changing the penalty from penaltychange => 20,2,2
    to penaltychange => 20,1,2
    in order to include Receptionist does not work either, as it will still not treat ‘Receptionist’, ‘Kelli’, ‘Traci’ equally as required.

    In THEORY (I’ve not tried this disgusting hack yet), I could use:

    [mrule]
    penaltychange => 20,2,2
    penaltychange => 40,3,3
    penaltychange => 80,4,4
    penaltychange => 120,5,5
    penaltychange => 150,6,6
    penaltychange => 180,1,1
    penaltychange => 200,2,2
    penaltychange => 220,3,3
    penaltychange => 240,4,4
    penaltychange => 260,5,5
    penaltychange => 280,6,6
    penaltychange => 300,1,1

    [myqueue]
    member => SIP/100.2,1,Receptionist member => SIP/100.2,2,Receptionist member => SIP/101.2,2,Kelli member => SIP/102.2,2,Traci member => SIP/100.2,3,Receptionist member => SIP/101.2,3,Kelli member => SIP/102.2,3,Traci member => SIP/103.2,3,Debi member => SIP/100.2,4,Receptionist member => SIP/101.2,4,Kelli member => SIP/102.2,4,Traci member => SIP/103.2,4,Debi member => SIP/104.2,4,Debbie member => SIP/105.2,4,Luci
    …and so on…

    🙂 See my problem?

    Cheers, Steve