[Home]

Summary:ASTERISK-00544: [patch] several improvements on app_queue/chan_agent
Reporter:Anthony Minessale (anthm)Labels:
Date Opened:2003-11-18 19:11:13.000-0600Date Closed:2011-06-07 14:04:44
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Applications/app_queue
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) app_queue.12.01.diff
( 1) app_queue.12.17.diff
( 2) app_queue.12.31.diff
( 3) app_queue.txt
( 4) asthash.c
( 5) asthash.c
( 6) asthash.h
( 7) asthash.h
( 8) chan_agent.12.01.diff
( 9) Makefile.12.01.diff
(10) q_min.gsm
(11) q_pos_is.gsm
(12) q_wait_time.gsm
Description:improvements such as customizable chime in sound files
to inturrupt the moh and play to the customer every so
many seconds as well as position/wait time announcement.
and a wait timeout to allow a max wait time before moving
on to the next priority in the extension
also a skillbased strategy allowing mutiple calls to be sent to the same queue with different skill requirements
and agents with defined skills

e.g. install queue has 3 entry points
1 for mac , 1 for pc , 1 for linux

each uses a different skill setting
so the agent can be tagged with the os he can help install

1 = mac 2 = pc 4 = linux 5 = linix+mac 6=linux+pc 7=linux+pc+mac

****** ADDITIONAL INFORMATION ******

attached is doc and gsm for position announcements
Comments:By: Anthony Minessale (anthm) 2003-11-18 19:13:16.000-0600

If it's not obvious the gsm all go in /var/lib/asterisk/sounds for
the chimelist to work
By: Brian West (bkw918) 2003-11-19 14:54:09.000-0600

I like.. I like... have you searched thru the bug tracker for the other two bugs... one I wrote.. and dave troy made better.. and one outolunch made for queue timeouts.... but this looks very clean.  I will try to test it tonight.

bkw
By: lambertpf (lambertpf) 2003-11-19 16:37:55.000-0600

I like this patch. But not everything is working for me. The "toolong" parameter works. But the "chimelist" doesn't. It only does the first item on the "chimelist" and then doesn't repeat the "chimelist". Any ideas?

queues.conf.....

[sales]
music = default
strategy = skillbased
timeout = 15
retry = 30
maxlen = 10
chimelist = announce_pos,digis-q-sales-announce
chimereps = 45
loopmin = 1
member =>Agent/@1
member =>SIP/711
member =>SIP/711b
member =>SIP/712
context = queue-sales

edited on: 11-19-03 22:13
By: Anthony Minessale (anthm) 2003-11-19 22:41:58.000-0600

When you are in postion 1 on the queue:

The frequecny of itterations was
('chimereps' * 'retry') because by design it sleeps 'retry' sec after
each cycle.

also in skillbased mode all people are considered at the head of
the line i.e. first come, first serve.  so you should probably
stay in ringall unless you like that behaviour.  

The reason for this is the current algorythm is from the perspective of the
call on the queue trying to find an agent and only the head of the line is
allowed this luxury so in skillbased mode all the calls fall into this loop
to give them all a fair chance otherwise if a guy was in line looking
for skill a and another guy was in line next looking for b
and you had 2 free b skilled agents poor mr b would never get his call answered.  because the 2 b agents dont have the 'a' skill and
the algorythm would not give up till the head call was taken.

I'd like to move the prespective to that of free agents looking
for an unaswered call to take because then you can consider mutiple
calls in mutiple queues and have a priority queue and a secondary membership
say "always pickup sales first but if there are none take tech support"
then a free agent with skill b can look at all the calls in all the skillbased
queue he belongs to and pick the nearest to the top who matches his skill.

In other words 'skillbased' is not perfect at this point but it works
considering the disclaimer above.

One may not want to use announce_pos cos there could be a situation
where you tell him he is position 4 and he gets the call picked up
right away but that is speculation on my part. most caller probably won't wait
much longer..

I will upload a newer patch to fix that time issue.





I patched the sleeper to sleep 1 sec and try to play the file
'retry' times and it is more faithful now to chimereps being 1 sec each
By: Anthony Minessale (anthm) 2003-11-19 22:47:40.000-0600

I read my previous banter and realized 1 part sounds misleading.

>One may not want to use announce_pos cos there could be a situation
>where you tell him he is position 4 and he gets the call picked up
>right away but that is speculation on my part. most caller probably won't >wait much longer..

to clarify I mean using announce_pos and skillbased together
the announce_pos and chimelist stuff work perfect now since that new patch.
By: lambertpf (lambertpf) 2003-11-19 23:41:44.000-0600

I understand why it didn't appear to be working. When in position 1 it would have taken 22 mins between chimes.
I used app_queue.11.9.diff against a fresh cvs and a portion failed but I manually applied the hunk that failed and now everything tests out good.
BTW, I actually do not need the "skillbased" strategy for my current application. I just tried that in an effort to troubleshoot the issue.
- many thanks
By: Anthony Minessale (anthm) 2003-11-20 09:42:22.000-0600

adding a new diff off of 11-20 cvs
By: Anthony Minessale (anthm) 2003-11-20 16:12:22.000-0600

uploaded app_queue.11.20a.diff

This even newer version implements secondary members.

Secondary members are exactly the same as the primary ones
except you can set a certian amount of time to expire before
allowing the call to be presented to a secondary member.

Also, once secondary members are permitted to take the call, the primary members will all have a chance at the call before any of the secondary members.



queues.conf
; how many seconds should we make a caller wait before making
; the call available to secondary agents (not set or -1=never 0=instantly)
allow_secondary=30

; regular member
member => Agent/1040,1,0 ; joan

; secondary member
secondary_member => Agent/1139,2,0 ; eric
By: Anthony Minessale (anthm) 2003-11-21 17:28:20.000-0600

DOH! had a bug in it here is the right diff
By: Anthony Minessale (anthm) 2003-11-24 15:10:18.000-0600

New app DynaQueue implemented

this patch also require patch 566
http://bugs.digium.com/bug_view_page.php?bug_id=0000566

So far Queue and DynaQueue take named args....

;Create a queue on the fly if it's not already there.
;then add yourself to that queue
; this is 1 way to use the context to route the call
; 1 generic context has ext 1 and 2 defined
; and evecuted goto based on the variables GOTO1 and GOTO2
;


; camp for bill
; no carraige return after dynaqueue it wont let me fix it
;;
exten => 4010,1,SetVar(GOTO1=whatever|1|1)
exten => 4010,2,SetVar(GOTO2=whatever|1|1)
exten => 4010,3,DynaQueue(queuename=billsq|chimelist=hold_or_dial|chimereps=10|Agent/1000|context=generic_camp)
exten => 4010,4,Queue(queuename=billsq|options=t)


[generic_camp]
exten => 1,1,Goto(${GOTO1})
exten => 1,2,Hangup

exten => 2,1,Goto(${GOTO2})
exten => 2,2,Hangup

[whatever]
exten => 1,1,SayUnixTime
exten => 1,2,Hangup

edited on: 11-24-03 15:05
By: Anthony Minessale (anthm) 2003-11-25 16:54:55.000-0600

updated to require asthash.c in /usr/src/asterisk
and asthash.h in /usr/src/asterick/include
By: Anthony Minessale (anthm) 2003-11-25 22:52:35.000-0600

11.25 has a huge bug in it use 11.25a
By: jrollyson (jrollyson) 2003-11-28 23:37:00.000-0600

; regular member
member => Agent/1040,1,0 ; joan

; secondary member
secondary_member => Agent/1139,2,0 ; eric

^--- For secondary members, why not have an additional reserve time argument to the member statement, and get rid of the secondary_member statement altogether.
By: Anthony Minessale (anthm) 2003-12-01 11:58:26.000-0600

Because the secondary members should always fall below the primary ones.
If you just set a reserve timer then they may get the call before a real member.  This comes into play more when a secondary member of 1 queue is
a primary member of another and you want to make sure the well placed primary
member is most likely to get calls from the queue which he is primarily assigned.  Thus to implement this with 1 linked list of members you
will have to itterate 2 times. 1 time to decide who the primary members are
and again to find the secondary. The same amount of data is stored the way it currently is implemented but you have a pre seperated list of each type of member.  


see updated files for newest version

*12.01 *removed "beep" from chan agent and added it to app_queue.
       (http://bugs.digium.com/bug_view_page.php?bug_id=0000585)
      *minor code changes.

edited on: 12-01-03 11:51
By: gunk (gunk) 2003-12-06 17:17:52.000-0600

Uhm... you need to change the include in asthash.c

#include "asthash.h"

If you use brackets, gcc can't find it.
By: Anthony Minessale (anthm) 2003-12-08 11:22:03.000-0600

asthash.h is meant to be put in /usr/src/asterisk/include

when you put it there the brackets will work.
By: gunk (gunk) 2003-12-24 23:55:32.000-0600

I like the options added to the latest patch:

chimelist = announce_only

and the ability to add a secondary member dynamically with AddQueueMember.

In testing, however, if repeat is set to 5 in queues.conf, then I'm getting 5 announcements.  Setting repeat to 1 resolves this issue.  This is something new to the latest patch, 12.01 worked fine.

Another bug I found, is that when app_queue starts ringing calls to secondary agents, the primaries will stop ringing.

Last, if there are no primary agents, then I can't put callers into the queue.

In my situation, I'd like to see this:

 - ring primary agents for 30 seconds
 - chime in
 - wait 10 seconds
 - ring primary agents for 30 seconds
 - chime in
 - wait 10 seconds
 - ring primary and secondary agents for 30 seconds
 - rinse
 - repeat

If there are no primary agents logged into the queue, I still want to be able to place calls in the queue, but I want secondary agents to ring immediately.

Other than that, great patch!
By: gunk (gunk) 2003-12-26 09:32:47.000-0600

Found another buglet in the patch.  aqm_exec() works fine for adding secondary members, but rqm_exec() isn't able to remove the secondary member.  I've looked at the code, and while it doesn't appear overly complex, I'm not seeing how to fix this.

I did manage to fix aqm_exec() so that it will place a caller into the queue with only a secondary member, but then the chimelist plays continuously.  Quite annoying.

edited on: 12-26-03 09:21
By: mlh (mlh) 2003-12-28 16:54:43.000-0600

When do you think this will be added to CVS?
By: Brian West (bkw918) 2003-12-28 17:18:55.000-0600

It won't.  app_queue and chan_agent are being re-written from the ground up by a few asterisk users.  These two parts of asterisk are a source for alot of deadlocks and other such issues.
By: Anthony Minessale (anthm) 2003-12-31 18:50:24.000-0600

12.31 (out of version numbers after this DoH!)
fixed all aforementioned bugs (I hope!)

converted RemoveQueueMember to use named args
and to support dynamic removal of secondary agents.

edited on: 01-01-04 13:31
By: Brian West (bkw918) 2004-04-16 17:58:13

I would like to see alot of this but this is WAY out of sync with cvs ... and I think ICD will do this and THEN some.. cvs co ICD (if you wanna play!)