Summary:	ASTERISK-13447: wrapuptime=0 in 1.6.0.1 and 1.6.0.3
Reporter:	Bryce Porter (x86)	Labels:
Date Opened:	2009-01-25 17:23:48.000-0600	Date Closed:	2011-06-07 14:03:11
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_queue
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	When you set wrapuptime=0 in queues.conf on any queue, persistent (afaik... did not try dynamic agents) members of that queue will randomly (more so than not) miss calls if they recently got off of the phone. It seems that when the wrap up time is set to 0, app_queue ignores the 0 and defaults the value to something around 10 seconds.
Comments:	By: Bryce Porter (x86) 2009-01-25 17:26:18.000-0600 <russellb> hm, it defaults to 0 <russellb> and if you set it to 0, it will stay as 0 ... <x86> interesting to know it defaults to 0, because by default it was picking some random length of time for the wrapuptime, somewhere around 10 seconds <x86> hence why I even bothered trying to define it in the first place By: Mark Michelson (mmichelson) 2009-01-30 13:51:24.000-0600 Hi x86, I can't seem to reproduce this at all. I've got some questions though. Are you using Agent channels? If you are, can you be sure that there is no wrapuptime set in agents.conf? Also, if you are using Agent channels, can you make sure that the channel variable AGENTWRAPUPTIME isn't being set somewhere, too? Are you sure that this problem is actually associated with wrapuptime and not something similar? app_queue will print a debug message (if you have core debug level set to at least 1) if the wrapuptime is preventing a member from receiving a call. Similarly, if you have a wrapuptime configured in agents.conf, you'll see a debug message when the wrapuptime expires. These would be telltale signs that wrapuptimes are what's actually affecting things. If you're not seeing messages about wrapuptime, then there could be some sort of device state delay that is occurring when the queue member hangs up. It may be worthwhile to issue a "queue show" command from the CLI after a member hangs up to be sure that they have correctly returned to the "not in use" state. By: Mark Michelson (mmichelson) 2009-02-05 15:00:52.000-0600 Anything new to report? By: Bryce Porter (x86) 2009-02-05 19:07:43.000-0600 Sorry for the delay. It is happening with static queue members on SIP channels, not Agent channels. I did check that the agents are in "not in use" state after taking a call, but Asterisk simply refuses to dial queue members that have just gotten off the phone within roughly 10-20 seconds. It seems like it's sporadic, as it happens frequently, but not every time. I would say about 90% of the time the issue is reproducible. Here is the queues.conf: [general]        persistentmembers = yes        autofill = yes        monitor-type = MixMonitor [service]        musicclass = default        ; Change to announce to agent what queue call is coming in on        ;announce = queue-markq        strategy = ringall        wrapuptime=0        timeout = 60        retry = 5        weight=0        autopause=no        announce-frequency = 90        periodic-announce-frequency=24        periodic-announce = mousty/busy-time        joinempty = yes        leavewhenempty = no        ringinuse = no        context = leavequeue        member => SIP/7000          member => SIP/7001          member => SIP/7002          member => SIP/7003          member => SIP/7004          member => SIP/7005          member => SIP/7006 [others]        musicclass = default        ; Change to announce to agent what queue call is coming in on        ;announce = queue-markq        strategy = ringall        wrapuptime=0        timeout = 60        retry = 5          weight=0            autopause=no        announce-frequency = 90        periodic-announce-frequency=24        periodic-announce = mousty/busy-time        joinempty = yes        leavewhenempty = no        ringinuse = no        context = leavequeue        member => SIP/7000          member => SIP/7001          member => SIP/7002          member => SIP/7003          member => SIP/7004          member => SIP/7005        member => SIP/7006 By: Mark Michelson (mmichelson) 2009-02-06 13:44:21.000-0600 Thank you for the feedback. I'll try mimicking this setup locally and report back. By: Mark Michelson (mmichelson) 2009-02-06 15:26:55.000-0600 I copied the general section and service queue into my queues.conf and made a couple of insignificant modifications (like changing the members to correspond to my SIP peers and changing the periodic-announce file to play a sound I have on my computer). I tried a couple of different tests. In one, I continually called the queue with the same phone and would randomly pick a different member to answer the call. I ran probably about 25 calls this way and did not reproduce the behavior. In the other test I ran, I had two callers in the queue. One of the calls was answered while the other caller waited. Doing things this way, I also saw that the waiting caller would immediately ring the queue member when the first call completed. This got me thinking a bit, and so let me specify a scenario, given your setup, where I can see the behavior you describe happening. Let's say that caller A calls the "service" queue. All the queue members' phones start ringing. Member 1 picks up the phone. While caller A and Member 1 are talking, caller B calls the "others" queue. Since both queues contain the same members, all the same people's phones ring again, except for member 1 since he is currently talking to caller A. Member 1 finishes talking to caller A and hangs up. Now what you will see is that all the other members' phones are ringing, but member 1's phone will not (until the timeout configured in queues.conf is reached). Does this sound at all like what you were seeing? Do you have to use multiple queues and have callers in both of them to reproduce the problem? By: Bryce Porter (x86) 2009-02-10 20:28:18.000-0600 No, even with a single queue the problem still happens, for example: Caller A calls into the queue, Member 1 answers. A couple of seconds (well more than the wrapuptime when set to 0) after Member 1 hangs up, Caller B calls into the same queue. Member 1's phone will not ring. By: Mark Michelson (mmichelson) 2009-02-12 14:41:08.000-0600 Thanks for the information. I think at this point I'm just about out of potential things I could ask for from you, aside from debug output. What I think would be helpful is seeing console output with verbose and debug turned to at least 4. The timeframe I'd like to see is a call entering a queue and ringing everyone, followed by a call entering the queue and not properly ringing the member that just hung up. If it is possible to simplify your setup and scenario so there isn't a bunch of noise from other operations on the console, it would be very much appreciated, but I certainly understand if this cannot be done. By: Bryce Porter (x86) 2009-02-23 20:31:08.000-0600 Please close this bug, as the end users were falsifying information. This is not a real issue, sorry for wasting your time. Thank you for your patience. By: Joshua C. Colp (jcolp) 2009-02-24 08:31:43.000-0600 Closed per reporter.